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Power Sources for the Galileo and Ulysses Missions 

by Gary L. Bennett 

The Galileo mission to Jupiter and the In selecting a power source for Galileo and 

Ulysses mission to explore the polar re- Ulysses, several daunting challenges had 

gions of the Sun presented a series of tech- to be overcome: the solar energy flux at Ju- 

nical challenges to the design, develop- piter is about 25 times less than it is at 

ment and fabrication of spacecraft power Earth (making solar power impractical); 

sources. Both spacecraft were designed to the temperatures are quite low ( ^ 130 K), 

fly to Jupiter. Ulysses, which was launch- an< I th e radiation belts are very severe, 

ed from the Space Shuttle Discovery (STS- Fortunately, the successful flights of the 

41) on October 6, 1990, used the immense Pioneer 10 and 11 spacecraft and the Voy- 

Jovian gravity to twist its trajectory out of a £ er 1 an d 2 spacecraft to Jupiter and be- 

the plane of the ecliptic and into a polar yond had shown that radioisotope thermo- 

path around the Sun in February 1992. electric generators (RTGs) could easily 

Launched from the Space Shuttle Atlantis overcome these challenges. (An RTG con- 

(STS-34) on October 18, 1989, Galileo will sists of a radioisotope heat source that 

arrive in December 1995 to conduct a 20- provides thermal power from the natural 

month exploration in orbit of the largest radioactive decay of the radioisotope fuel to 

planet in the solar system. a converter that converts the thermal 



Figure 1. Diagram of the Galileo Orbiter and Probe showing the two general-purpose heat source radio- 
isotope thermoelectric generators (GPHS-RTG) mounted on the two booms. The length of a GPHS-RTG is 
113 centimeters (about 45 inches). Galileo is a NASA spacecraft mission to Jupiter, designed to study the 
planet’s atmosphere, satellites and surrounding magnetosphere. Fully loaded with rocket fuel, the Orbit- 
er has a mass of about 2400 kilograms (weight of about 5230 pounds). The Probe, which is designed to en- 
ter the atmosphere of Jupiter, has a mass of 340 kilograms (weight of about 750 pounds). 
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power into electric power by means of a 
number of solid-state thermoelectric ele- 
ments.) 

After some design changes dictated by the 
failure of a competing thermoelectric tech- 
nology and by modified user requirements, 
both missions settled on a common but 
then unbuilt power source known as the 
general-purpose heat source RTG or 
GPHS-RTG. Performance requirements for 
the GPHS-RTG were dictated by the space- 
craft requirements and the launch vehicles 
(Space Shuttle originally with Centaur up- 
per stage). The principal requirements 
were levied on power (at launch, at begin- 
ning of mission and at end of mission); 
structure (ability to withstand launch vi- 
brations and pyrotechnic shock); magnetic 
field strength (low enough to avoid inter- 
fering with the science instruments); mass 
properties (a low mass was desired and the 
center of mass was tightly controlled be- 
cause of spacecraft balance concerns — 
particularly in the case of Ulysses, which 
has the GPHS-RTG mounted directly on 
the side); pressurization (ability to hold a 
cover gas during ground operations); nucle- 
ar radiation (as low as practical); and great 
functional attributes. 

In outward appearance, the GPHS-RTG is 
basically a cylinder of 42.2 centimeters 
across the fins and 114 centimeters in 
length with a mass of about 56 kilograms 
that provides about 300 watts of electrical 
power at the time of assembly. As such it is 
the largest, most powerful RTG ever flown. 
The Galileo spacecraft has two GPHS- 
RTGs and the Ulysses spacecraft has one 
GPHS-RTG [Bennett et al. 1986 and 
Schock etal. 1979]. 

The overall mission schedule impacted the 
GPHS-RTG program in a number of ways. 
Originally Ulysses was to be a two-space- 
craft mission called the International 


Solar-Polar Mission; budget considerations 
forced NASA to drop its spacecraft, which 
led to the cancellation of the requirement 
for one of the GPHS-RTGs. Then the Gali- 
leo spacecraft switched from a Voyager- 
class RTG to the GPHS-RTG, requiring a 
net gain of one GPHS-RTG to be produced 
plus a common spare that had to be com- 
patible with two spacecraft that operated 



Figure 2. Diagram of the Ulysses spacecraft show- 
ing the general-purpose heat source radioisotope 
thermoelectric generator (GPHS-RTG) mounted on 
the side. Ulysses is a European Space Agency (ESA) 
spacecraft mission that was launched by NASA and 
has some U.S. experiments designed to study the 
polar regions of the Sun. 

The biggest impacts were the launch dates 
and launch vehicles. Both kept shifting. 
While launch dates obviously drive deliv- 
ery schedules, the launch vehicle drives the 
details of the design. All of these changes 
and the tight schedules (given the fixed 
budgets) contributed to a very tense focus- 
ing of the program. Fortunately, there was 
an early agreement on the basic require- 
ments for the GPHS-RTG which allowed 
some stability — at least in that area! 
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A number of technical issues were con- 
fronted early in the program and success- 
fully overcome through focused team ef- 
forts. The following sections describe some 
of these issues, followed by some personal 
observations on the process and lessons 
learned. 

Il l Technical Issues 

The following subsections provide a gener- 
al su mm ary of some of the major technical 
issues encountered during the GPHS-RTG 
program. 

Restarting Thermoelectric Production. 
The thermoelectric elements used in the 
GPHS-RTGs were of the same basic design 
as the thermoelectric elements in use on 
the Voyager power sources. However, dur- 
ing the production campaign for the Voy- 
ager program, the thermoelectric elements 


had been manufactured by what was then 
the RCA Corporation. After the completion 
of that program, RCA ceased its thermo- 
electric activities, so when the GPHS-RTG 
program began, the system contractor, 
General Electric Company (GE) [later Mar- 
tin Marietta Astro Space], had to establish 
its own thermoelectric production line. 

Small modules consisting of 18 thermoelec- 
tric elements each were manufactured and 
put on test to evaluate the GE product and 
to determine if GE had been able to dupli- 
cate the RCA product. Differences were un- 
covered that led to the formation of an in- 
vestigative team of representatives from 
GE and several Department of Energy 
(DOE) support contractors and laborato- 
ries. The team reviewed the process and 
product requirements in detail and uncov- 
ered some material deficiencies that were 
quickly corrected. 


r HEAT SOURCE , COOLING TUBES 



V MIDSPAN HEAT 
SOURCE SUPPORT 


"GENERAL PURPOSE 
HEAT SOURCE 


Figure 3. Cutaway drawing of the general-purpose heat source radioisotope ther “®® 1 ®^” C e f f 1 ® 
(GPHS-RTG). The GPHS-RTG consists of two major components: the general | 

(GPHS) and the converter which converts the thermal power generated in theGPHS mto electrical po 
er by means of 572 thermoelectric elements called “unicouples The overall diameter of the GPHS^TG 
with fins is 42.2 centimeters (about 16.6 inches). The mass of the GPHS-RTG is about 55.9 
(weight of about 123 pounds). The GPHS-RTG produces over 300 watts of electrical power at the time of 
assembly The GPHS-RTG has no moving parts and should provide power for over 20 years after launch. 
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Perhaps more important was the discovery 
that actual RCA practices had gone beyond 
documented specification and process re- 
quirements, which led to the explicit writ- 
ten incorporation of these practices along 
with more detailed instructions, tighter 
limits, control of more parameters and 
more detailed descriptions and control of 
the facility conditions. Facility changes 
and improved training were completed and 
a real-time trend analysis system was im- 
plemented to record and track key param- 
eters, enabling prompt consideration of 
process deviations [GE 1991]. 

Developing a New Radioisotope Heat 
Source. The radioisotope heat source that 
powered the GPHS-RTG was a new design 
that had improved safety features designed 
to immobilize the plutonia fuel under all 
credible accident scenarios, including im- 
pact on Earth following a postulated atmos- 
pheric reentry from space [Snow & Zocher 
1978, Snow et al. 1978, and Schock 1980]. 


Production of the radioisotope heat source 
components ran into a common problem: 
every time a component moved from the 
laboratory to production, defects were dis- 
covered. In each case, inter-laboratory 
teams were established to discover the 
cause of the defects. 

Developing the Assembly and Testing 
Facility. The GPHS-RTG program was 
operationally conducted in a new way: a 
DOE laboratory instead of the system con- 
tractor had responsibility for the assembly 
and testing of the power sources [Amos and 
Goebel 1992]. In order to accomplish this 
transition in the shortest possible time and 
ensure the safety of the RTGs, a team com- 
prised of representatives from the system 
contractor (GE), the heat source laboratory 
(DOE’s Mound Plant) and other involved 
contractors and laboratories was employed 
to work the design, procedures and train- 
ing in real-time. The use of practice hard- 
ware, detailed procedures, real-time check - 



1' An W ?^n^ e ^ 1 i CO m,' germanium unicou P le (thermoelectric element). 572 of these 

Q sed * in ea f ch ( f PI J S Q RT( ?: The um £? u P le le »gth is 311 centimeters and the hot shoe mea- 
sures almost 2.3 centimeters by 2.3 centimeters. The hot shoe operating temperature is about 1305 K. 
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ing, and constant training allowed the suc- 
cessful completion of the Galileo and Ulys- 
ses power sources. One innovation in the 
assembly and testing operation was to use 
a team of knowledgeable people to examine 
the next steps in a process just before they 
were to be completed to ensure that noth- 
ing in the process, tooling or facilities could 
damage the RTG. In effect, this was a sort 
of “advance quality assurance.” 

j j A Unique Management Approach 

The GPHS-RTG program involved a limit- 
ed “production run” within a tight sched- 
ule and budget which required each power 
source to meet specifications — there was 
no extra hardware or time for mistakes. 
Success mainly was due to well-defined ob- 
jectives with real-time problem solving 
and a minimum of bureaucratic interfer- 
ence. The GPHS-RTG program was spared 
the excesses of outside advice and over- 
sight that seem to plague most government 
programs today. The government program 
office had full authority and responsibility 
to manage the program within the budget- 
ary and schedular constraints. 

The GPHS-RTG program was managed 
from a small, proactive headquarters-level 
government program/project office that 
numbered at most about 12 people, includ- 
ing two secretaries and several managers 
who had other responsibilities. This office 
was totally responsible for the program, in- 
cluding the system, heat source, safety, re- 
liability and quality assurance, and tech- 
nology, which spanned four contractors 
and seven government laboratories (total- 
ing over 300 people during the different 
program phases). All contracting and bud- 
geting were done through headquarters, 
and the laboratory program guidance was 
issued from headquarters. A program with 
as many organizations as the GPHS-RTG 
program had cannot delegate responsibil- 


ity to the field and still expect the program 
to come together. In essence the GPHS- 
RTG program was conducted with central- 
ized control and decentralized execution. 

Some key advice from the government pro- 
gram office’s quality assurance program re- 
quirements includes making sure that 
[Sommer 1982]: 

• Requirements are clear and unambigu- 
ous. 

• Design requirements are adequately 
specified. 

• The design is compatible with fabrica- 
tion, nondestructive testing, inspection 
capabilities, and that the fabrication 
process is adequate to yield the neces- 
sary quality hardware as defined in the 
contract or program guidance. 

• The design lends itself to testing at var- 
ious levels of assembly and the testing 
process is adequate to yield the required 
information without degradation of 
hardware quality. 

• The design lends itself to assembly , op- 
erations, storage and shipment. 

• Parts, materials and processes are se- 
lected on the basis of proven experience 
or qualification for the intended use. 

• Cleanliness and contamination specifi- 
cations for materials and processes are 
consistent with design requirements. 

• Safety requirements are specified and 
procedures are established to ensure 
their adequate implementation. 

An interagency agreement between NASA 
and DOE defined the roles and responsibil- 
I ities for the two agencies in the GPHS-RTG 
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program. Top-level interface specifications 
and drawings were jointly signed off by 
DOE and the NASA project office at the Jet 
Propulsion Laboratory (JPL). The top-level 
requirements were in turn translated into 
contractual requirements for GE and into 
program guidance to the national laborato- 
ries. All requirements were worked with a 
view toward achieving mutual agreement 
between the involved organizations. GE 
was the system contractor and DOE’s 
Mound Plant, working under the system 
requirements, was responsible for all of the 
heat source activities. 

To meet the schedule meant turning on ev- 
erything at once (a technique now often re- 
ferred to as “simultaneous engineering,” 
“concurrent engineering” or “integrated 
product development”). Reliability, quality 
assurance and safety were incorporated 
from the beginning. This parallel approach 
meant constant attention to the technical 
and programmatic interfaces. The program 
office personnel met regularly with the 
contractors and laboratories, typically on a 
monthly basis and more often as the situa- 
tion dictated. Program office personnel 
served on the major teams that were estab- 
lished to work the various problems. The 
customer (JPL) was also regularly in- 
volved in the program. In the beginning of 
the heat source production campaign, 
monthly meetings of the key organizations 
permitted a number of interface issues to 
be worked quickly between the involved 
parties. Throughout the program, the par- 
ticipants engaged in regular, informal con- 
tact and discussion. Hardware, tooling and 
facilities were visited on a regular basis. 
On-site representatives were used as need- 
ed (for example, GE had one or more repre- 
sentatives at Mound; DOE and its quality 
assurance laboratory had representatives 
at GE; and on occasion, Mound personnel 
worked directly with personnel at the oth- 
er heat source laboratories). Problems were 


not allowed to fester. In order to meet the 
schedule, each problem had to be addressed 
as it occurred. 

The program was managed with a strong 
focus on schedule — the overriding objective 
was to deliver the requisite RTGs to specifi- 
cation on time and within budget. There 
were real-time inspections, materials re- 
view boards (MRBs), failure review boards 
(FRBs), and process reviews. The quality 
control inspectors were on the line doing 
their work in real time. Faxes and tele- 
phone calls were used to expedite the ap- 
proval process — the schedule did not per- 
mit the bureaucratic practice of letting the 
mail room handle the distribution of ac- 
tions. 

One of the outstanding resources of the 
GPHS-RTG program was the heritage of 
experienced personnel (the “RTG culture”) 
at most of the facilities. Most of the key 
people knew each other and understood 
their capabilities and roles. These people 
were in the program for the “long haul” 
and they had a positive “can do” attitude. 
All of the organizations had a history of in- 
volvement in RTG programs. As a result, 
the various organizations were able to 
work as a team, forming task forces as 
needed to solve problems. Responsibilities, 
accountability and control were well de- 
fined. The government program office also 
maintained a check -and-balance approach 
as needed through the judicious use of its 
own people and independent organizations. 

The government program office used an op- 
erations analysis to assess the facilities, 
procedures and training at each site before 
the RTG or heat source arrived there. The 
operations analysis team looked at the var- 
ious environments to which the RTG hard- 
ware might be exposed. The team included 
representatives from the other organiza- 
tions involved. 
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Figure 5. Cutaway view of the general-purpose heat source (GPHS) module components and assemblies. 
Eighteen of these modules are in each GPHS-RTG. 


Readiness reviews were conducted at each 
step in the process to ensure that docu- 
ments were complete, that the require- 
ments and test plan were complete, that 
the incoming articles were as built (identi- 
fication and verification of the configura- 
tion), and that the test equipment was cali- 
brated. Tooling was under control. Data 
packages were prepared to document the 
hardware and how it was built and tested. 
Finally, before the GPHS-RTGs were ship- 
ped to the Kennedy Space Center (KSC), a 
formal flight readiness review was con- 
ducted; it covered the contractual require- 
ments and the flight worthiness of the 
hardware and checked to ensure that ev- 
erything was in place for the shipment. 

The government program office controlled 
the Class I changes to specifications and 
procedures; that is, changes dealing with 
safety, performance, reliability, inter- 
changeability, qualification status and in- 
terface characteristics (“form, fit, function, 
and safety”). The government had repre- 
sentatives on the MRBs and the FRBs. 


One of the lessons from past RTG programs 
was the need for constant attention to de- 
tail. Everything must be documented and 
tracked. Full documentation is just good 
engineering and scientific sense because it 
facilitates investigations into problems 
that may come up. Relying on specifica- 
tions is no guarantee of the quality of the 
final product — the processes must be under 
strict control, too. Like its predecessor pro- 
grams, the GPHS-RTG program began 
with component testing and moved on to 
subsystem and full-up system testing be- 
fore the flight hardware was built and 
flown. (It is worth noting that even while 
today’s quality programs emphasize one- 
time inspection, the GPHS-RTG program 
did uncover cases where receiving inspec- 
tions caught problems not identified in the 
sending inspection.) 

To meet the schedule meant freezing the 
design as early as possible and sticking to 
that design, unless problems necessitated 
consideration of a change. Every program 
is faced with the better idea or technology 
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that comes along after the design is frozen, 
but as long as the existing design meets 
the design requirements, changes should 
be avoided because they can cause enor- 
mous confusion and delays. The old adage, 
“better is the enemy of good enough,” is 
true. 

In addition to sticking to the frozen design, 
the program must also stick to the test pro- 
gram and avoid unnecessary tests. The 
GPHS-RTG program was a flight program, 
not a research program. 

Finally, it is important to return to the 
matter of people. Large, complex programs 
cannot be run by committee or diffuse man- 
agement structures. To paraphrase Charles 
Sheffield, large projects have been built in 
the past and in their day they, too, chal- 
lenged the state of the art. “The problems 
that they ran into were often horrendous 
and all different, but the really successful. . . 
have had one thing in common: associated 
with each, obsessed by each, you will find a 
single individual . . . The Manhattan Proj- 
ect is a prime example of a group effort. 
There were dozens of scientists working on 
the atomic bomb whom history has judged 
as geniuses. But at the top, following ev- 
erything at a level of detail that even his 
fellow workers found mind-boggling, was 
one man: Robert Oppenheimer. Through 
the 1960s, when NASA had just nine years 
to put a human on the Moon, a handful of 
staff— -Wernher von Braun, George Muel- 
ler, and George Low — poked into everyth- 
ing and tracked everything.” [Sheffield 
1991.] 

Fortunately for the GPHS-RTG program, 
there were also a handful of people who 
checked into and tracked everything. 
These people were obsessed with the suc- 
cess of the GPHS-RTG program and they 
were personally committed for the dura- 
tion of the program. 


IH Lessons Learned 

From the foregoing and the author’s exper- 
iences in managing the safety and nuclear 
operations elements of the GPHS-RTG pro- 
gram, the following lessons were learned: 

• Dedicated, trained people working as a 
team are the first key to success. All of 
the organizations involved in the pro- 
gram need to understand their individ- 
ual roles and responsibilities. Account- 
ability is crucial, but with accountabil- 
ity must go the authority and the re- 
sources to do the job. 

• The design requirements should be 
fixed early in the program and the prin- 
cipal ones should not be changed except 
as required by the exigency of the pro- 
gram and then only through a formal, 
disciplined process of reviews and ap- 
provals. 

• A central program office should have 
complete authority and responsibility to 
manage the program. There must be a 
centralized decision process for the 
“form, fit, function, safety” of the pro- 
gram. Outside reviews and “help” must 
be minimized and the budget should 
match the requirements and schedule. 

• Training is essential in every aspect of 
the program. Technicians should be for- 
mally qualified (preferably with written 
certificates) for each process they are 
asked to perform. The training must be 
realistic and current, and done with re- 
alistic practice hardware. 

• The procedures must be sufficiently de- 
tailed to cover every step of the process. 
Nothing in the procedures should be left 
to chance or interpretation. (The author 
found one case in which a procedure 
called for a component to be “washed” 
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but the washing was not specified. One 
technician did it one way; another tech- 
nician did it a different way. Needless 
to say, product differences were found.) 

• The facilities must be clean, orderly, 
worker friendly and suitable for the 
tasks. (In checking into a problem with 
one metal alloy, the author found the 
metal pressing was being done in an old 
building with a hole in the roof — and 
the hole was above the location where 
the material was being worked!) It 
helps immensely if the facilities, equip- 
ment and tools are dedicated to the pro- 
gram and kept under the control of the 
program. If not, there must be formal 
reviews each time before the facilities 
and equipment are used to ensure that 
they are ready for the process. (In an- 
other program the author worked on, 
some technicians working on a second 
program borrowed a gas management 
console, and when it was returned, the 
valve settings had been changed and no 
one was informed. The technicians on 
the first program did not check this and 
almost destroyed a power source by ad- 
mitting the wrong gas.) 

• The laboratory work done to develop a 
process or material or component must 
be done with the same documented rig- 
or as the final production work. Invari- 
ably one of the reasons that the produc- 
tion people found problems with a 
laboratory-developed product was that 
the laboratory people were not using 
the same quality control inspection 
techniques and tools as the production 
people. Also, there is a tendency in lab- 
oratory work not to document the work 
to the detail necessary to develop pro- 
duction procedures that will yield a re- 
producible product. 


• To meet the schedule, the whole team 
must operate with a sense of urgency. 
Paperwork, reviews and approvals must 
not be allowed to lag. Quality control in- 
spections and review board activities 
must be done in real time. However, at 
no time should schedule be the excuse 
for not producing a quality product that 
meets the requirements. 

• A test philosophy of building and test- 
ing hardware through increasing levels 
of assembly should be employed. For the 
GPHS-RTG program, the thermoelec- 
tric elements were first built and tested, 
followed by the testing of 18-element 
modules. Then full-scale engineering 
units were built and tested for structur- 
al, mass properties and electrical tests. 
After the engineering units had proven 
the design, a full-scale radioisotope- 
heated qualification unit was built and 
tested to qualify the overall RTG de- 
sign. Finally, the four flight RTGs were 
assembled and tested. Supporting this 
test program were engineering analy- 
ses, component testing and materials 
characterizations, and throughout there 
was a constant attention to detail. 

• There must be agreement between the 
sender /producer and the receiver /user 
on the inspection procedures and the in- 
spection tools to avoid problems where 
the producer sends something that 
passes the producer’s inspection only to 
see it rejected by the user. 

• Independent operational analyses and 
advanced process reviews must be con- 
ducted to ensure that personnel and fa- 
cilities are ready to receive and work on 
the hardware. With limited hardware, 
the protection of the product is of para- 
mount importance. 
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Four flight power sources (three flight 
RTGs and a common spare) were success- 
fully assembled and tested for use on the 
Galileo and Ulysses spacecraft. The three 
GPHS-RTGs in use on the Galileo and 
Ulysses spacecraft have met all power per- 
formance requirements to date [Bennett et 
al. 1994], In summary, the GPHS-RTG 
power sources performed as required, were 
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Managing Requirements 


by Ivy F. Hooks 


Several years ago, I called upon an old ac- 
quaintance who had recently assumed 
management of a troubled program. I told 
him that I would like to help him manage 
his requirements. He told me that he did 
not need any help because he had asked 
the advice of a mutual friend and NASA 
manager. That advice was: “Just say ‘no’ to 
all proposed changes.” 

This was not necessarily bad advice, it was 
just not appropriate to this manager s 
problem. A major problem with the pro- 
gram was that it had very poor require- 
ments that could not be satisfied within 
budget or schedule. I have no idea what the 
program manager actually did, but the 
program has since been canceled. 

You may be surprised to learn that you are 
not really managing requirements. Pro- 
gram managers tend to focus on subjects 
other than requirements. This occurs be- 
cause of a bad assumption— the manager 
assumes that everyone knows how to write 
requirements, thus the requirements pro- 
cess will take care of itself. 

Most program managers have technical 
backgrounds, and will focus on the non- 
technical aspects of the program that are 
new and alien. New program managers 
know that they do not fully understand 
budgets, so more attention goes to budgets. 
Since the program manager’s boss will fo- 
cus on budgets and not on requirements, 
the program manager places more atten- 
tion on that which interests the boss. 

Most people understand that bad assump- 
tions are traps just waiting to get you, and 


this bad assumption — requirements will 
take care of themselves — is no different. 
This paper examines how this bad assump- 
tion can wreak havoc with a program, the 
types of problems that occur because of this 
bad assumption, and what NASA program 
managers can do to improve their require- 
ment management process. 

HI Failure to Manage Requirements 
Affects Programs 

If the program requirements are not well 
understood, there is not much hope for esti- 
mating the cost of the program. In today’s 
environment — 15% overrun and your pro- 
gram may be canceled — it is foolish to bud- 
get incorrectly. But you cannot budget cor- 
rectly without a good set of requirements. 

Werner Gruhl developed a history of NASA 
programs versus cost overruns (Figure 1). 
He attributed much of the problem of cost 
overruns to the failure to define the pro- 
gram properly in Phase A and B so that 
good cost estimates could be made. 

Even with the best cost estimate, many 
programs will encounter overruns because 
of changing requirements. This phenom- 
enon is one the aforementioned program 
manager was trying to avoid. The time to 
avoid this problem is not in Phase C or D 
but at the beginning of the program. There- 
fore, I interpret the Gruhl chart differently. 
If you have not done a good job in Phase A 
and B in defining and confining your pro- 
gram, including documenting the require- 
ments, you are going to encounter large 
numbers of changing requirements and the 
cost will go up accordingly. 
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Total Cost 


Figure 1. Effect of requirements definition invest- 
ment on program costs. By Werner M. Gruhl, Chief, 
Cost and Economic Analysis Branch, NASA Head- 
quarters. 

The relationship between program cost 
and requirements is cyclic (Figure 2). You 
cannot affect one without affecting the oth- 
er, but program managers try. Budgets are 
cut, but the program manager tries to keep 
the requirements intact. There are some 
occasions where a design change will save 
money and all requirements will still be 
met, but this a rare occurrence. 



Figure 2. Cyclic effect. 

It is almost impossible to change any re- 
quirement without affecting the net cost. 


Unfortunately, it seems that this is heavily 
biased in one direction, i.e., any change to a 
requirement results in an increase in cost. 
Even when you delete or reduce a require- 
ment, you will encounter some cost — you 
cannot make a change with paying. Hope- 
fully, deleting or reducing a requirement 
will result in a net savings. 

It seems obvious that requirements drive 
program costs and that changing require- 
ments are a major driver of cost overruns. 
Poor requirements contribute to the need 
for change. 

It is important to understand the type of er- 
rors that occur in requirements in order to 
avoid these errors and subsequent changes. 
An IEEE study (Figure 3) shows types of 
non-clerical requirement errors. In this 
study, the ambiguities and inconsistencies 
make up about 20% of the errors, and omis- 
sions account for another 31%. The largest 
number of errors (49%) were for incorrect 
facts. Most of the incorrect “facts” that I 
have encountered come from incorrect as- 
sumptions. 



Omission 


Misplaced 

requirement 


Ambiguity 


Figure 3. Types of non-clerical requirements errors. 
1981 IEEE Computer Society, Inc. 
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The “cost of assumption error” chart (Fig- 
ure 4) has been presented by many differ- 
ent companies and organizations over the 
years. The chart shows the relative cost 
over the software life cycle to correct an 
“assumption error.” If identifying and cor- 
recting the error during the requirements 
definition phase cost you $1.00, it will cost 
from 40 to 1000 times as much to fix if not 
identified until the operations phase. The 
cost to Fix the error rises rapidly as you pro- 
ceed into the life cycle. I suspect that you 
only need to add a few zeros to the multipli- 
ers to reflect the cost for hardware pro- 
grams. 


I' 000 



Figure 4. Cost of assumption error in requirements 
phase. “Extra Time Saves Money Warren Kuffel, 
Computer Language, December 1990. 

The information in this figure is also appli- 
cable to other requirements changes. If you 
decide to change a requirement at the be- 
ginning of the program, the cost will be 
minimal compared with making a change 
after you have begun development or when 
you are in operations. 

These two previous figures indicate the im- 
portance of controlling all assumptions and 
all requirements from the beginning of the 


program. Gruhl’s chart shows the impor- 
tance of devoting resources to Phase A and 
B efforts. 

Given the evidence of poor requirements 
definition and management as the cause of 
program cost overruns, why do program 
managers continue to make the same mis- 
takes? 

HI Major Problems in Requirements 
Management 

The major cause of bad requirements is 
that people do not know how to write re- 
quirements. The problem is compounded by 
a lack of management attention and a poor- 
ly defined requirements management pro- 
cess. If the program manager assumes that 
1) everyone knows how to write require- 
ments; 2) the requirement definition pro- 
cess is well understood; and 3) the review 
process will fix any problems, then prob- 
lems are guaranteed. 

1. Everyone does not know how to 
write requirements. Very few people 
really understand how to write good re- 
quirements. In each of my courses, I ask 
the class, “How many of you have had to 
write requirements?” then, “How many of 
you have had to review or verify someone 
else’s requirements?” Most respond to one 
or both questions. Then I ask, “How many 
of you have been happy about either pro- 
cess?” Rarely does anyone respond to the fi- 
nal question. 

The problem is that, while these are very 
bright people, they sense a lack of manage- 
ment interest, are not provided the infor- 
mation needed to do a good job, and do not 
have the knowledge to do the job. 

Lack of Interest. Writers of requirements 
can sense a lack of management interest. 
Emphasis is on schedule — getting a specifi- 
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cation written so that a procurement can 
be conducted — not on quality. Most have 
never seen anyone recognized for doing a 
good requirements writing job, and none 
has seen anyone suffer for having done a 
poor job. Hence, they do the best they can, 
given limited information, time and guid- 
ance. Not surprisingly, the resulting re- 
quirements will need to be rewritten many 
times before the program is complete. 

Nearly 1,500 NASA and contractor person- 
nel have been through our Requirements 
Definition and Management Course. A re- 
curring response to the post-class survey is 
“my management does not understand this 
process” and “my manager does not sup- 
port my doing this work.” This should be a 
red flag to all NASA managers. 

Lack of Information. The NHB 1720.5 re- 
quires documentation of the scope of large 
programs and projects. The program plan 
is essential for all size programs and pro- 
jects. Without this information, it is impos- 
sible to get good requirements. No one can 
write good requirements without a clear 
understanding of the scope of the project, 
its mission and operational concepts. Each 
requirements author needs to know the 
goals, objectives and constraints associated 
with the program. 

In fact, no one can write good requirements 
in a vacuum. If the program manager does 
not supply the scope, each individual au- 
thor will define a scope. Each individual 
will probably define a unique scope and the 
resulting requirements will be responsive 
to a variety of concepts, objectives and con- 
straints. This in an invitation to disaster. 
NASA has established the process, but it is 
up to each program and project manager to 
ensure that the content, quality and time- 
liness of the program plan supports the re- 
quirements development process. 


Lack of Knowledge. Engineers at NASA 
frequently are asked to write, review, de- 
sign to, or verify requirements very early 
in their careers. They may not have ever 
heard the word “requirement” in college. 
They have an idea of what they are to do, 
but their ideas and examples of existing re- 
quirements may be all wrong. If manage- 
ment is not prepared to mentor and assist 
these new engineers, they will do their 
best, but it will not be good enough. Some 
people with many years of experience do 
not appreciate the importance of good re- 
quirements or what it takes to write good 
requirements. Some of these people may be 
trying to mentor, but they also lack the 
necessary knowledge. 

Recently, a division chief was reviewing a 
report that I had written against a set of 
system requirements. The report showed 
the current requirement, explained what 
was wrong with it, and provided a rewrite. 
His response was, “I would have thought 
these current requirements were okay.” He 
was just being honest, although he lacks 
the knowledge to help his people. In fact, 
the lack of sufficient and knowledgeable 
mentors has affected all levels of NASA 
personnel. 

Only requirements that are necessary, at- 
tainable and verifiable should appear in a 
specification. If the requirement authors 
are apprised of this and held accountable, 
there is some chance of creating a valid 
specification. Each of these attributes is es- 
sential to good requirements, and further 
details are provided later in this paper. 

2. The requirement definition process 
is not well understood. Many view the 
requirement definition process as only ma- 
jor milestones: release of a specification for 
the Request for Proposal (RFP) and a Sys- 
tem Requirements Review (SRR). The pro- 
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cess involves many steps to reach the 
milestones, but these are often ill-defined 
or not communicated to the team. 

A disciplined program manager must as- 
sure that the steps are clearly defined and 
communicated, ample time is allotted, and 
a qualified team is assembled to ensure a 
good specification. Otherwise, the result 
will be a poor specification, tons of Review 
Item Disposition (RID) forms and more ef- 
fort in the review than was ever expended 
in the requirement definition process. 

Too many cooks can spoil the broth, espe- 
cially if each is using a different recipe, i.e., 
working without a well-defined program 
plan. Too often, NASA’s approach to re- 
quirements is to invite everyone to create a 
wish list, which creates unnecessary, un- 
verifiable and unattainable requirements. 
To solicit requirements from a large group 
of people, you must provide them with the 
program plan and insist that their require- 
ment be responsive to your plan. You must 
instruct them to justify each requirement, 
just as you will require them to justify each 
future change. You must educate them 
about defining only requirements that are 
necessary, verifiable and attainable. 

You need to use concurrent engineering in 
defining requirements. This is essential to 
ensure that all requirements are captured 
in the initial definition phase, not after de- 
sign, testing or operations are underway. 
This means having not only the customer, 
user and functional area designers in- 
volved in the process, but also participants 
from safety, reliability, manufacturing, 
test and operations. 

Failure to include this cross-disciplinary 
group in the requirements definition pro- 
cess can result in a system that exceeds 
costs for manufacturing, is unreliable, and 
that will cost a fortune to maintain and op- 


erate. Too many problems will be found too 
late in the program life cycle, and the pro- 
gram costs and schedules will overrun sig- 
nificantly, as indicated in Figure 4, 

The requirement definition process needs 
strong, experienced, system-oriented per- 
sonnel to help elevate detailed engineering 
discipline requirements to real system re- 
quirements. Discipline engineers will tend 
to write requirements as though for their 
discipline, resulting in detailed subsystem 
definition before the system design is done. 
It is not unusual to see a system specifica- 
tion with requirements that read: 

The guidance and navigation 

subsystem shall. . . 

The failure and warning system shall. . . 

The communications subsystem shall. . . 

These are not system requirements, and 
they play havoc when a contractor designs 
your system and develops lower level re- 
quirements. A strong systems engineer can 
assess the real needs and develop system- 
level requirements from those proposed by 
discipline engineers. 

Requirements defined by scientists also re- 
quire a good systems engineer to interpret 
and translate science requirements into en- 
gineering requirements. Many NASA Cen- 
ters handle science requirements, and the 
subject arises repeatedly in our training 
classes. The engineers are frustrated in two 
areas. They see no constraints on the sci- 
ence requirements — they could be simply a 
wish list. In fact some scientists seem to 
feel that they are entitled to ask for any- 
thing on a NASA program, since they do 
not have to pay for it. Management must 
control the science requirements just as 
rigorously as engineering requirements. 
Are they necessary? Are they attainable? 
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The second frustration is one of translating 
science requirements into engineering re- 
quirements. Centers that repeatedly face 
this challenge need a team of experts to do 
this job. Scientists know what they want 
but are often unable to write an appropri- 
ate specification. Engineers who under- 
stand what the scientist wants and can 
translate this into a valid and verifiable 
system requirement are very valuable. 

To ensure proper translation, each require- 
ment written in response to a science re- 
quirement should clearly document the as- 
sumptions made and how the translation 
was conducted. Then the scientist should 
be asked to approve the engineering re- 
quirement(s) and review the operational 
concept and implementation before base- 
lining. It is important to select the right 
team of people and to put in place the right 
processes with reasonable schedules in or- 
der to succeed in the requirements defini- 
tion phase of the program. 

3. The review process cannot fix all 
problems. If you have produced a very 
good set of requirements, selected knowl- 
edgeable people for the review process and 
managed the review properly, you will be 
rewarded with a set of recommendations to 
improve your program. If you have failed 
to do any one of these steps, the review pro- 
cess will be a waste of time and money. 

The review completion allows you to move 
into the next phase of the life cycle. But a 
review of poor documents, no matter how 
well-conducted, will increase your program 
risk. You will not have identified all the 
necessary items and you will be redefining 
throughout the next phase, leading to in- 
creased costs and schedules slips. 

Some large NASA programs have recently 
had more than 7,000 RIDs against a single 
document. This is inexcusable. First of all, 


the document being reviewed was too poor 
to have been released in the first place. It 
should have been cleaned up considerably 
before being allowed out for review. This is 
clearly a management problem. 

Second, there were too many inexperienced 
reviewers. Managers have told me that 
they had no control over who reviewed the 
document. This is ridiculous; this is a pro- 
gram cost and it should be controlled. 
Many of the reviewers stated that they 
were expected to write a certain number of 
RIDs. The reviewers were often inexperi- 
enced and so wrote individual RIDs for ev- 
ery editorial comment — these will certain- 
ly get the numbers up. 

Management should provide instructions 
for the review. These should include stat- 
ing that all editorial RIDs can be placed on 
a single form. You might question why, 
with grammar and spelling checkers avail- 
able on all word processors, there are any 
editorial RIDs at all. All participants in the 
process should be qualified as having some 
knowledge in both the process and the pro- 
gram before they are allowed to write 
RIDs. This may take some effort on the 
part of management, but not nearly as 
much effort as struggling through hun- 
dreds of useless RIDs. 

II Improving the Requirement 
Management Process 

Steps to improving requirement quality 
and the requirement management process 
are straightforward and can be implement- 
ed with minimal cost and extraordinary re- 
sults. The first step is to ensure that a good 
program plan — containing goals, objec- 
tives, constraints, missions and operation- 
al concepts — is available to all participants. 
The second step is to establish a well- 
defined requirement definition process and 
to educate the participants to their respon- 
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sibilities. It is essential that each partici- 
pant be aware of the characteristics of good 
requirements: necessary, verifiable, and 
attainable. Requirement definition must 
include tests of these characteristics. 

Necessary. I once requested that an engi- 
neer withdraw a requirement, since it was 
unnecessary. The engineer said, “No, let 
my manager take it out if he wants to.” 
Odds are the manager will not catch the 
problem. Responsibility, authority and ac- 
countability must be identified and en- 
forced. Responsibility should be imposed at 
all levels, but it ultimately rests with the 
program manager. Every requirement 
should be clearly understood before the 
first draft is released, not during CDR. 

Each requirement should be examined as 
rigorously as each change will be examined 
in the future. The first time a requirement 
appears, you should treat it as though it 
were a change that will cost your program 
a great deal of money. You need to know 
why the requirement is needed and any as- 
sumptions that were made by the author. 
These are questions you will ask for each 
change — ask them now. All requirements 
should be in response to your program 
plan. If they are not, they may not be nec- 
essary. 

Attainable. It is a waste of time and mon- 
ey to write unattainable requirements. If 
the effort is for new technology, then there 
may be a question about the technical abil- 
ity to attain the requirement. This can be 
handled by tracking the requirement as a 
risk. Unattainable requirements often 
come into being because the original au- 
thor does not know what is needed. The 
Space Station requirements have been 
through many iterations. Unfortunately, 
no rationale or justification was captured 
in the process. As some items are converted 


from contract to GFE, it has become appar- 
ent that unattainable requirements were 
written and never caught. 

One recent problem requirement affected 
the use of the Global Positioning Satellite 
(GPS). The requirement was for an accura- 
cy unattainable by the GPS. When ques- 
tioned, it was divulged that no one had 
computed a required value, but an engi- 
neer had simply guessed that a certain val- 
ue was attainable and entered it into the 
requirements. Management had not ques- 
tioned the value. The requirement will 
have to change and someone will need to 
determine the correct value. Remember 
Figure 3, in which 49% of the requirements 
errors were incorrect “facts”? 

Many unattainable requirements are tech- 
nically feasible but still unattainable. You 
do not need requirements that exceed your 
budget; even if they are technically feasi- 
ble, they are unattainable. Unmanaged au- 
thors will write requirements for many 
items that would be “nice to have” but are 
really unnecessary or unattainable due to 
budget and schedule constraints. It is the 
job of program management to prevent this 
from occurring. 

Verifiable. It is hard to believe that there 
are engineers and managers who do not 
know that all requirements must be veri- 
fied. It is important to analyze each re- 
quirement in light of how it will be verified 
as it is written and before it is baselined. 
This is not the case on all programs. Last 
year a change request was written for the 
Space Station Freedom Program to correct 
or delete over 100 un verifiable require- 
ments from the system specification. One 
can only wonder how more than 100 un- 
verifiable requirements had remained in 
the document through so many reviews 
and scrubs. 
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A good check against unverifiable require- 
ments is a simple test of word usage. Words 
and phrases like maximize, minimize, sup- 
port, adequate, but not limited to, user 
friendly, easy, and sufficient are subjective 
and thus unverifiable. Verification costs 
are often a major element of the program 
cost. Removing unverifiable requirements 
and specifically addressing how each re- 
quirement will be verified, prior to base- 
line, can help to control this cost. 

Accountability. The most significant step 
that needs to be taken in improving the re- 
quirement process is that of accountability. 
Accountability is important for each indi- 
vidual requirement. You need to assign 
ownership as requirements are written. 
The owner should be a person with a stake 
in the requirement and who is knowledge- 
able about the need for the requirement. 
The owner should be willing and able to de- 
fend the need for the requirement prior to 
baseline. The owner should be available to 
assess change impact against the require- 
ment should a change be proposed. 

Accountability is even more important at 
the management level. There has been a 
trend for large numbers of people to sign a 


specification. I have seen instances where a 
division chief, an associate director and the 
director signed the specification, but not 
the program/project manager. These sign- 
ers had not read the document. The pro- 
gram manager should sign and be held ac- 
countable. Higher managers can sign if 
they wish, but if they sign they should be 
held accountable. 

The quality of the requirements should be 
part of each program manager’s evaluation 
criteria. The quality and stability of the re- 
quirements that they manage are essential 
to program success and should be a meas- 
ure of their own success. 

Anyone offered a program manager’s job 
should look carefully at the condition of the 
requirements left by the predecessor. If the 
requirements are out of control, no other 
control, short of cleaning up the require- 
ments, will enable the program to be suc- 
cessful. 

What all program managers should recog- 
nize is that the investment to obtain good 
requirements is minor compared to the ef- 
fect on program cost and schedule, and pos- 
sibly, the manager’s career. 
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Program Control on the Tropical Rainfall 
Measuring Mission 

by Dorothy J. Pennington and Walter Majerowicz 


The Tropical Rainfall Measuring Mission 
(TRMM), an integral part of NASA’s Mis- 
sion to Planet Earth, is the first satellite 
dedicated to measuring tropical rainfall. 
TRMM will contribute to an understand- 
ing of the mechanisms through which 
tropical rainfall influences global circula- 
tion and climate. Goddard Space Flight 
Center’s (GSFC) Flight Projects Director- 
ate is responsible for establishing a Project 
Office for the TRMM to manage, coordi- 
nate and integrate the various organiza- 
tions involved in the development and op- 
eration of this complex satellite. 

The TRMM observatory, the largest ever 
developed and built inhouse at GSFC, in- 
cludes state-of-the-art hardware. It will 
carry five scientific instruments designed 
to determine the rate of rainfall and the to- 


tal rainfall occurring between the north 
and south latitudes of 35 degrees. As a sec- 
ondary science objective, TRMM will also 
measure the Earth’s radiant energy budget 
and lightning. 

The complexities of managing an inhouse 
project are magnified by many non-GSFC 
interfaces, as shown in Table 1. The TRMM 
Project Office is responsible for managing 
the integration of all segments of this com- 
plex activity and providing a cohesive team 
that will deliver a fully functioning obser- 
vatory within budget and schedule con- 
straints. These interfaces require careful 
management and coordination of technical, 
schedule and budget elements. While the 
project office provides overall program 
planning, direction and control, the subsys- 
tem managers and instrument suppliers 


Table 1. TRMM Organization Responsibilities 


Component 

Responsible Organization 

Project Management 

TRMM Project 

Observatory Subsystems 

Engineering Directorate/numerous aerospace 
companies 

Precipitation Radar (PR) 

Japan/ NASDA/Toshiba 

TRMM Microwave Imager (TMI) 

TRMM Project/Hughes 

Visible Infrared Scanner (VIRS) 

TRMM Project/Santa Barbara Research Center 

Clouds and Earth's Radiant Energy System 

(CERES) 

EOS/Langley Research Center/TRW 

Lightning Imaging Sensor (LIS) 

TRMM Project/Marshall Space Flight Center 

TRMM Science Data and Information 

System (TSDIS) 

Earth Sciences Directorate/General Sciences 
Corporation 

Mission Operations 

Mission Operations and Data System Directorate 

H-ll Launch Vehicle and Launch Services 

Japan/NASDA 

Science Team 

Earth Science Directorate, U.S. Universities, JPL, 
NOAA, Japan, Australia, Israel, France, Taiwan, 
Great Britain 
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implement project requirements at a de- 
tailed level. One immediate challenge to 
securing a successful TRMM mission is im- 
plementing program control systems that 
will ensure an August 1997 launch from 
Tanegashima Space Center, Japan. The 
August 1997 launch is critical; if TRMM is 
not launched on time, high levels of solar 
activity forecast for the late 1990s would 
result in a reduced mission life. This con- 
straint, along with the limitation of bian- 
nual launch windows at the Tanegashima 
Space Center, places top priority on sched- 
ule performance, but not at the expense of 
technical excellence, safety or cost. 

iH Program Control Overview 

The TRMM Program Control staff has es- 
tablished a comprehensive Program Con- 
trol System that includes schedule man- 
agement, financial management, configu- 
ration management and risk management. 
The Program Control System is not simply 
a computer program. Rather, it consists of 
a series of checks and balances in each of 
these areas that are designed to keep the 
entire management system integrated, as 


shown in Figure 1. Four monthly reports 
reflecting analyses in the areas of schedule, 
finance, general business and risk manage- 
ment are generated by the TRMM program 
control staff. These reports, called the Pro- 
gram Control Monthly Status Reports 
(PCMSR), are distributed to TRMM techni- 
cal and resources management and provide 
a current, complete analysis of all business 
issues and concerns. TRMM also conducts 
monthly status reviews with each of the 
subsystem, instrument and element man- 
agers. During these reviews, each manager 
is allocated approximately 30 minutes to 
present technical, cost, schedule and man- 
power issues and concerns to the TRMM 
Project Manager. The importance placed on 
communication, whether through these re- 
views or in the PCMSR, is one of the key 
reasons behind the success of the Program 
Control System. 

A major element of the Program Control 
System is the logic network. Using the pro- 
ject work breakdown structure, the project 
planners developed an end-to-end network 
that was baselined shortly after the TRMM 
System Concept Review. 
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This network, in conjunction with the mis- 
sion specifications and agreements, pro- 
vided the foundation for project manage- 
ment to focus on the preparation of the 
budget estimates. Careful consideration 
was given to technical and schedule risks 
and tradeoffs while attempting to deter- 
mine annual funding requirements. After 
the technical, schedule and cost baselines 
were established, the TRMM Configura- 
tion Control Board (CCB) was set up to sys- 
tematically consider all changes to the 
baselines. Finally, the risk management 
report was initiated by the Program Con- 
trol staff to provide project management 
with an ongoing early warning system. Us- 
ing this mechanism, actions to resolve cost, 
manpower, schedule and technical prob- 
lems can be quickly identified and imple- 
mented. Frequent communication between 
project managers, subsystem managers, 
instrument suppliers and the program con- 
trol staff is the key to maintaining these ef- 
fective management systems. 

ifi Schedule Management 

The scheduling function is centralized at 
the project level. The scheduling staff is as- 
signed to the project office and coordinates 
with both GSFC and outside organizations 
responsible for the development of the 
TRMM spacecraft, instrument, and ground 
segments as well as overall system inte- 
gration and test (I&T). 

The TRMM Program Control staff has de- 
veloped a comprehensive logic network for 
TRMM that integrates key work tasks and 
milestones from all elements within the 
TRMM system. For work being performed 
at GSFC, the schedulers prepare the sub- 
networks in coordination with the respon- 
sible subsystem and element technical 
managers. For work being performed 
outside of GSFC, schedule data is received 


from the contractors’ scheduling systems 
and incorporated into the TRMM schedule 
database. 

A sample portion of the logic network is 
contained in Figure 2. The information 
contained in the activity boxes or “nodes” 
identifies the task description, activity du- 
ration in work days, and total slack (the 
amount of time an activity or event can be 
delayed before it impacts launch readi- 
ness). With the use of TRMM's automated 
scheduling system for developing and 
maintaining the logic network, bar charts 
are easily generated. The bar chart corre- 
sponding to the logic network sample pre- 
sented in Figure 2 is shown in Figure 3. 
These detailed schedules are “rolled up” to 
an intermediate level in order to summa- 
rize the schedule information for manage- 
ment. Figure 4 depicts how the Thruster 
detailed schedule is summarized within the 
Reaction Control Subsystem (RCS) Inter- 
mediate Schedule. This “roll-up” or sched- 
ule summarization capability, combined 
with the precedence relationships among 
the activities in the logic network, provide 
the framework to properly manage the ver- 
tical and horizontal schedule integration 
and traceability on TRMM. 

For effective Program Control of TRMM, 
maintaining a schedule baseline is as im- 
portant as maintaining a technical and cost 
baseline. Moreover, proper configuration 
management of the TRMM schedule is vi- 
tal in order to accurately assess the impact 
of changes. TRMM’s formal schedule base- 
line is identified in the TRMM Project 
Schedule Baseline Document (PSBD). The 
PSBD consists of three parts: major project 
milestones, project control milestones and 
the Observatory integration and test 
schedule. The schedule for these milestones 
can only be changed with the approval of 
the TRMM Configuration Control Board. 


21 



TRMM THRUSTER LOGIC NETWORK 


Program Control on the Tropical Rainfall Measuring Mission 



Figure 2. RCS Thruster Logic Network Diagram 
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Figure 3. RCS Thruster Detailed Schedule Bar Chart 
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The major project milestones provide the 
framework for overall planning and sched- 
uling for the TRMM spacecraft segment, 
instrument segment, and ground segment 
developments, system integration and test, 
shipping and delivery, and launch site 
preparations. These milestones, depicted 


at the top of the Master Schedule (see Fig- 
ure 5) consist of the System Concept Re- 
view (SCR), Preliminary Design Review 
(PDR), Critical Design Review (CDR), Pre- 
Environmental Test Review (PER), Pre- 
Shipment Review (PSR), and the Launch 
Readiness Review. 



Figure 5. TRMM Project Master Schedule 
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The project control milestones are events 
which the TRMM Project Office considers 
critical. These include, but are not limited 
to, interface milestones such as the deliv- 
ery of hardware or software between 
TRMM organizational elements. Control 
milestones can also represent the comple- 
tion of major stages of work within a given 
subsystem or element. More importantly, 
they are commitments by the responsible 
organizations to the TRMM Project Office 
to accomplish these events as planned. 

Next, the TRMM I&T schedule is included 
in the PSBD because it establishes the 
need dates for flight hardware and soft- 
ware. Considerable emphasis was placed 
on establishing the I&T schedule soon after 
the SCR in February 1991. Moreover, be- 
cause all of the TRMM elements ultimate- 
ly come together during integration and 
test, the I&T schedule has become the 
“hub” of the overall scheduling process. It 
is a key planning tool for all of the ele- 
ments of the spacecraft, instrument and 
ground segments. 

Since the logic network is a continuously 
evolving tool, it is not directly contained in 
the PSBD— only the project control miles- 
tones are. However, the logic network sup- 
ports the schedule baseline in that a target 
version of the network is maintained 
against which the current status is com- 
pared. This concept is illustrated in the 
sample bar chart presented earlier (see 
Figure 4). The compressed black line below 
each activity bar or milestone represents 
the schedule baseline at the detailed work 
task level. This provides a correlation be- 
tween the current schedule and the base- 
line. Unilateral changes to the logic net- 
work by the responsible subsystem or tech- 
nical managers are permitted, provided 
they do not impact the project control 
milestones or necessitate rephasing of the 
budget. 


Schedule status accounting on the TRMM 
Project occurs formally each month. Work 
already underway or activities that should 
have started or been completed since the 
last accounting period are statused by de- 
termining the percentage of work accom- 
plished, the amount of time remaining to 
complete a task, or the new expected finish 
date of a task. For the work being per- 
formed at GSFC, the responsible subsys- 
tem technical managers are interviewed by 
the schedulers in order to obtain schedule 
status. In this way, the schedulers receive 
not only the status, but also the rationale 
and issues affecting the status. Once the 
raw status is input into the logic network 
data base, it is processed, analyzed and 
verified. This allows schedule issues to be 
identified, resolved or addressed before sta- 
tus is formally reported in the TRMM 
Monthly Project Review. For TRMM’s sci- 
entific instruments, schedule status is re- 
ceived from the instrumentors each month 
and analyzed prior to incorporation into 
the logic network. 

The key driver in the TRMM schedule is 
the August 16, 1997 launch readiness date. 
In addition to monitoring the actual 
progress of work toward launch readiness, 
the TRMM schedulers carefully analyze 
schedule slack. Total slack is a specific, 
quantitative and easily understood mea- 
sure of schedule health. Figure 6 depicts 
the TRMM Total Slack Summary, which 
presents an overview of progress for a giv- 
en month. The chart highlights the key ele- 
ments for the spacecraft, instrument and 
ground segments. Each month the total 
slack for the worst case item within each 
element is elevated to the total slack chart. 
It is compared to total slack from the pre- 
vious month, as well as the total slack for 
that item in the schedule baseline. The 
benefit of this chart is that TRMM project 
managers can see the overall health of the 
TRMM project schedule at a glance. 
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Figure 6. TRMM Total Slack Summary 


The schedule products such as bar charts 
and network diagrams are important Pro- 
gram Control tools for TRMM. When com- 
bined with a formal status process, they 
enable the TRMM Project Office to assess 
the progress of the TRMM schedule. As an 
early warning mechanism, the scheduling 
system provides a means to detect poten- 
tial schedule problems, implement wor- 
karound plans, or take corrective action in 
order to mitigate problems. Scheduling 
products are tailored to various members 
of the TRMM team. Tools such as the Total 
Slack Chart and the Intermediate Sched- 
ules provide a way to summarize a tremen- 
dous amount of detailed schedule data for 
TRMM project management. With this in- 
formation, management can identify key 
issues, critical paths and potential work- 
arounds. At the working level, detailed 
schedule bar charts and logic network dia- 
grams are excellent planning tools. 


In summary, the TRMM scheduling system 
provides reliable information to all levels 
of users. 

li Financial Management 

A key feature of the Program Control Sys- 
tem is cost and schedule integration. As 
with the scheduling staff, the financial 
staff is centralized at the project level — 
although other GSFC organizations also 
provide financial support for TRMM sub- 
system managers. The main duty of the fi- 
nancial staff is budget formulation and ex- 
ecution. The logic network schedule serves 
as a basis for TRMM budget planning. 
Based on a detailed integration and test se- 
quence, need dates for flight hardware and 
software have been precisely identified. 
Budgets were formulated against the time- 
frame reflected in the schedules, as illus- 
trated in Figure 7. 
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Figure 7. TRMM Cost/Schedule Integration 


By integrating cost and schedule planning, 
the project office can perform what-if bud- 
get and schedule simulations. Civil ser- 
vant manpower and travel budgets were 
also developed using the schedule to deter- 
mine the correct phasing of requirements. 
In a dynamic budget environment, the 
TRMM Project is quickly able to isolate the 
impact of schedule delays, personnel short- 
ages and travel cuts on the budget require- 
ments. Similarly, when budgets are re- 
duced, the integrated cost and schedule in- 
formation provides a framework to quickly 
determine the scope of work that can be re- 
programmed without having undesirable 
effects on launch readiness. 

The TRMM Project has already used this 
system to identify numerous planned early 
year, high-cost component purchases that 
could be deferred to later years, thereby al- 
leviating funding problems without risking 
the integration and test schedule. 


Close coordination between the subsystem 
and element managers and the TRMM fi- 
nancial staff ensures timely and accurate 
preparation of budget estimates and pro- 
curement requests. Since TRMM is an in- 
house project, the procurement activities 
are not focused on several large prime con- 
tracts, as typically found in other GSFC 
projects. Instead, the financial and procure- 
ment staffs are responsible for purchasing 
the components, parts and instruments 
that will come together as a complete ob- 
servatory. These extensive procurement 
activities require detailed planning and co- 
ordination to remain on schedule. 

The budget was developed for these pro- 
curements and supporting effort as discrete 
items at the Job Order Number (or work 
package) level. The budget requirements 
were then “rolled-up” through the project 
work breakdown structure by month and 
fiscal year, which ensures that budget data 
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submitted to NASA Headquarters is based 
on the detailed estimates for the entire pro- 
ject. As part of the financial system, the 
TRMM financial staff has developed an ex- 
tensive contingency tracking system. De- 
tails of all changes in the budget baseline 
are maintained in the contingency (man- 
agement reserve) tracking system as 
shown in the summary portion of Table 2. 
This provides a complete audit trail of all 
items funded from the contingency line 
item. 

In addition to budgeting and procurement 
responsibilities, the financial staff ana- 
lyzes contractor financial performance and 
ensures that other members of the TRMM 
project team are kept abreast of financial 
issues and concerns. The TRMM Micro- 
wave Imager contract has requirements for 
modified Performance Measurement Sys- 
tem (PMS) reporting. On a monthly basis, 
the financial staff prepares a quick-look 
analysis of the PMS data in the TRMM 
Program Control Monthly Status Report. 
Analyses are also prepared for other con- 
tracts and for fiscal activity. 

Configuration Management 

TRMM’s integrated program control ap- 
proach also closely aligns cost and schedule 
management with configuration manage- 
ment (CM) activities. TRMM’s configura- 
tion management system provides a disci- 
plined approach for controlling the changes 
to the requirements in hardware, software, 
performance, schedule and cost. Budget, 
schedule and technical requirements were 
established as integrated baselines early 
in the project’s life. As changes to the es- 
tablished baselines occur, they are formal- 
ly presented to the TRMM CCB. 

The CCB, composed of technical and ad- 
ministrative representatives from each 
project discipline, evaluates the positive or 


negative impact of each change on the bud- 
get, schedule, and technical baselines. 
With this integrated, accurate approach to 
cost and schedule assessment, the impact of 
engineering changes can be quickly and 
thoroughly evaluated across the project. 
The TRMM Project Office has a goal to 
evaluate all changes within 45 days of the 
initial change request. A work progress in- 
dicator for the CM process has been incor- 
porated into the Risk Management System. 

§§j Risk Management 

Risk management is another key element 
of TRMM’s integrated program control pro- 
cess. The Risk Management System em- 
phasizes detection and resolution of prob- 
lems in areas identified as having risk po- 
tential. The system allows managers to 
identify program risks and to implement 
alternate plans to mitigate the impact of 
unresolved problems, as shown in Figure 8. 
Cost, schedule and technical risk param- 
eters have been identified for TRMM to 
quantitatively measure program health 
and ultimately program risk. 

Figure 9 shows the elements of the project 
that are tracked in the monthly Risk As- 
sessment Report. Technical indicators in- 
clude power, mass, data rate and mission 
life. Management indicators include fi- 
nance, schedule, configuration manage- 
ment, manpower and procurement. These 
risk indicators have been identified to pro- 
vide a quantifiable goal against which 
progress is measured. Each indicator has 
three tolerance levels or alert zones used to 
indicate the level of risk. 

First, risk is classified as a major impact if 
the indicator’s performance reflects the ex- 
istence or imminent threat of major prob- 
lems, concerns or similar severe impacts 
upon accomplishment of project require- 
ments. 
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Table 2. Contingency Tracking System 
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Figure 8. TRMM Risk Management Process 
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Figure 9. TRMM Risk Assessment Summary 
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Second, the risk is identified as a potential 
impact if performance reflects the exis- 
tence of problems, concerns or potential 
impacts on the project unless timely and ef- 
fective action is taken. In the third cate- 
gory, the risk poses no negative impact on 
meeting TRMM cost, schedule and techni- 
cal requirements. When an alert zone 
threshold is passed, an analysis is conduct- 
ed by the responsible manager to deter- 
mine the cause of the problem and a correc- 
tive action plan is generated to restore the 
indicator to the desired state. The Risk Re- 
duction Plan documents these products 
and provides an audit trail for the project 
to assign, track and close the corrective ac- 
tions. 

Figure 10 illustrates the risk indicator 
summary for the TRMM Configuration 
Change Requests. The project recognizes 
that failure to act upon change requests in 
a timely manner could affect the project’s 
ability to accomplish cost and schedule 
goals. The alert zones reflect the project’s 


Configuration Changes 

Purpose: To track the status of engineering 

changes (Class I) in terms of timely 
action to avoid schedule and/or cost 
impact. 

Data ground rules: 

• Track age of Configuration Change 
Requests (CCRs) 

• Change quantity measured by count of 
approved change logged into 
configuration control. 

Alert zones: 

CH No Impact Age of CCR less than 45 

or days 

Potential Impact Age of CCR between 45 

or and 60 days 

Hi Major Impact Age of CCR over 60 days 

Figure 10. TRMM (CCRs) Indicator Summary 

goals for the disposition of all change re- 
quests in 45 days. The accompanying sta- 
tus shown in Figure 1 1 provides a monthly 
record of TRMM’s performance against 
these pre-established thresholds. 



Figure 11. TRMM Project Configuration Change Requests 
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When the assessment is unfavorable, a 
Risk Reduction Plan is generated (Figure 
12) which analyzes the cause, impact and 
corrective action. The thresholds for the 
alert zones were set jointly by the responsi- 
ble subsystem manager and the project 
manager, and are intended to represent a 
reasonable goal for that indicator. These 
thresholds were sometimes adjusted sever- 
al times in the preliminary months of the 
Risk Assessment Report until all parties 
felt that the appropriate goals were reflect- 
ed accurately. 

Figure 13 shows the risk indicator for the 
RCS schedule slack. This indicator, used 
for all subsystems and instruments, tracks 
slack trend status. Each month, the actual 
slack is compared to pre-established 
thresholds and risk reduction plans are 
generated as needed. 


In RCS, the January 1993 slack dropped to 
16 days due to a technical change in the 
thruster configuration. Since the first risk 
threshold of 32 days was passed, a Risk Re- 
duction Plan was generated (Figure 14). 
This problem was resolved in May 1993 by 
negotiating an earlier delivery with the 
vendor at contract award, with no addition- 
al cost. This action increased the thruster 
slack to 33 days. With the thruster slack no 
longer in an alert zone, attention was then 
focused on the element with the least 
amount of slack, the Propellant Control 
Module (PCM). 

The risk management system has allowed 
the project staff to effectively use con- 
strained resources to focus on problems 
which could negatively impact cost, sched- 
ule or technical objectives. Although the 
system requires a great deal of discipline, 


Log Numb* 


TRMM PROJECT RISK REDUCTION PLAN 


Problem Description Name of Indicator 

Originator Date Phone Number 


Chock tho Alort Zono that applies: 

■ Major Impact S3 Potential Impact □ No Problem, but has 

unfavorable trend 

Potential Impact: Cost Schedule Technical Performance 

Describe Problem 

1. Summarize problem, identify cause, quantify impact to cost schedule technical performance. 


□ Ho Problem, but 
RRP desirable 


2. List hardwire and/or software configured items affected. 


Corrective Action Plan (Be specific, include dates when problem is expected to be resolved, attach separate schedule H necessary.) 


Functional Manager Concurrence 


Project Manager Concurrence 


Figure 12. TRMM Project Risk Reduction Plan 
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Figure 13. TRMM Reaction Control Subsystem Total Slack 
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planning and teamwork, the ultimate re- 
sult focuses the entire project team on the 
critical problems. To date, the TRMM Pro- 
ject has succeeded in acheiving its cost and 
schedule goals, and the TRMM Project Of- 
fice can provide GSFC and NASA manage- 
ment with very reliable status and forecast 
information. The TRMM Project Office’s 
proactive management approach empha- 
sizes prevention rather than correction. 
The ability to provide early warning and 
quick-reaction analysis when changes oc- 
cur allows the team to make informed de- 


cisions and to optimize positive results. 
TRMM technical, resource and manage- 
ment personnel clearly understand their 
role in aggressively managing their re- 
sponsibilities. TRMM’s commitment to ex- 
cellence, teamwork and communication 
will ensure the development of a high- 
quality satellite, delivered on schedule and 
within the approved budget. This progres- 
sive management system is one of the 
TRMM Project’s contributions to improv- 
ing NASA project management effective- 
ness and efficiency. 
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An unmistakable trend in management 
views its role as a support system to work 
that flows horizontally across the organi- 
zation. The work conducted by people who 
are chosen from across the company work 
in joint participation as a team to fulfill 
the needs of customers. The actions and 
behaviors of these people, as well as the 
actions and behaviors of people who sup- 
port them, constitute a project. The cre- 
ation and orchestration of these actions 
and behaviors is project management. The 
trend is thus toward viewing the com- 
pany’s organization as providing support 
to these teams who satisfy the needs of 
customers through the conduct of projects. 

Coordination and orchestration of the pro- 
ject team’s actions and behaviors are the 
responsibility of one of the team members, 
a project manager. The project manager, 
sometimes likened by Peter Drucker to the 
conductor of a symphony, in general will 
not possess all the competencies necessary 
to fulfill the needs of the customer, but, 
nonetheless, is empowered by the com- 
pany to fulfill these needs. This method of 
management is the project management 
method. Is it new to NASA? No; in fact, 
NASA pioneered some of the basic notions 
of the method. Is it being appropriately 
implemented? In some places, yes. But fre- 
quently people have different views of 
what project management is, what their 
role should be, and how to implement it, 
all of which can result in disharmony. 

About five years ago at a PPMI planning 
session, while discussing management de- 
velopment needs of NASA staff and how 
these needs were being addressed in one of 
JSC’s project management courses, an in- 


vited staffer asked: “Why do we need all 
that human factors stuff in the course? 
What does that have to do with project 
management?” 

Before the industrial era, tailors, carpen- 
ters, shoemakers, milkmen and black- 
smiths all knew their customers by name. 
As Edwards Deming points out, they knew 
whether their customers were satisfied and 
what was required to satisfy them. In the 
industrial era, one individual could not pos- 
sess, much less understand, all the compe- 
tencies necessary to satisfy customers, so 
companies were formed. These early com- 
panies often likened themselves to king- 
doms and governments of the 17th or 18th 
centuries, where people did not own things 
or feel a sense of participation, but were 
subservient to the management of the com- 
pany. Individuals did what they were told 
to do and had their place. 

Such systems of government did not sur- 
vive when competing with those following 
the French and American revolutions. 
These new governments were based on a 
new order founded by Hobbes, Locke and 
Rousseau, who asserted that all citizens 
have the right to own and keep things. Sys- 
tems designed to incorporate this valued 
right of individuals would outperform sys- 
tems that did not incorporate this right. 

Companies now tend to have management 
systems that foster greater participation 
and ownership by project team members. 
They are designed to take into account dif- 
ferent cultures and values (personal, corpo- 
rate and societal), different cognitive man- 
agement styles, the nature of the project 
and the business situation. 
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Basic behaviors on which the project man- 
agement method is built are much the 
same as those stressed by Drucker and De- 
ming, in versions of TQM, ISO 9000, etc., 
and they can be easily remembered with 
the help of an acronym, C.O.S.T. Each let- 
ter stands for a concept basic to the meth- 
od: Customer, Ownership, System and 
Teamwork. 

jjjjf§ Customer 

As the blacksmith was an extension of a 
farmer’s need for iron work, NASA project 
team members are likewise extensions of 
needs of their customers, who can be inter- 
nal or external to the Agency. The first op- 
portunity to create defective work is to 
misunderstand a customer’s needs. Time 
spent ensuring that the project objectives 
and requirements are clearly understood, 
communicated and agreed upon has an im- 
mediate impact on improving project qual- 
ity, reduction of reworks, and reduction in 
the number of costly changes. The project 
manager should ask: Who are my custom- 
ers? Do I talk to them directly? Am I sure 
that I understand their true needs? Are we 
communicating with customers clearly? 

iH Ownership 

Outside of the valued rights of life and li- 
berty first set forth by Hobbes, Locke and 
Rousseau, a most cherished value is owner- 
ship. The greater the participation in es- 
tablishing project and task objectives by 
the team members who can do the work, 
the stronger will be their attachment and 
sense of ownership of that work, and the 
more likely it will be that the objectives 
are met. 

The project manager should ask: Has the 
project team developed a breakdown of the 
work with tasks whose outputs are work 
products? Is someone responsible for these 


work products? Do we have a project orga- 
nization that has a one-to-one relationship 
with the work breakdown (one name in 
each box)? Is the project organization well 
known, and has it been coordinated with 
other unit managers? 

||| System 

The project management system consists of 
creating behaviors in three functional 
areas: Planning, Leadership and Control. 

Planning. Planning is determining what 
needs to be done, by whom, when and at 
what expense of resource in order to fulfill 
the customer’s needs. Without planning, a 
project will be out of control, in free fall, 
i.e., “It’s over when it’s over” because there 
is no basis for control. 

Five basic management tools are used to 
create appropriate planning behaviors. The 
extent and rigor of their use must be al- 
lowed to differ, because projects, people and 
situations differ. Even for the smallest pro- 
ject, each tool is used. 

1. Project Objectives. The behavior cre- 
ated by the development of project objec- 
tives is concurrence and agreement with 
customers. Costly mistakes are fre- 
quently made by having poorly estab- 
lished objectives that contribute to high 
change traffic, defects in service, poor 
relationships and mistrust. In effective 
project management, a lot of time is 
spent in making sure objectives are 
clear, measurable, verifiable and agreed 
to, and that risks are understood. 

2. Work Breakdown Structure (WBS). 
The behavior created by developing a 
work breakdown is control behavior. 
The WBS enables project team members 
to stand back and see how their part fits 
into the project as a whole, to see if any- 
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thing is missing, and how the project 
might be better organized or broken 
down further. An approach to control- 
ling work is to divide it into smaller 
pieces and then to control the pieces. If 
the pieces are still too large and compli- 
cated, then those pieces are broken into 
yet smaller ones, and so on. There are 
many views and opinions on how pro- 
jects should be broken down, and there 
are many different work breakdowns 
that are possible; however, the best 
work breakdown is that which will best 
control the work; that is, control of 
quality, schedule and budget. 

3. Project Organization. The behavior 
created by developing a project organi- 
zation is accountability and ownership. 
One individual’s name should be associ- 
ated with each task of the work break- 
down. If an individual cannot be identi- 
fied at the time of planning, the name of 
the line manager who will provide that 
individual to the team should be associ- 
ated with the task. If there are tasks 
without names, what should be of con- 
cern is . . . Who will define the objectives 
for these tasks? If it is someone other 
than the one who will do the work, the 
probability of ownership of the work de- 
creases and the probability of defects 
delivered to the customer increases. 

4. Project Schedule. The behavior being 
created by a project schedule is commu- 
nications across the project team, with 
company management and with cus- 
tomers. “The problem,” says one expert, 
“is that our fascination with the tools of 
management often obscures our igno- 
rance of the art.” What comes out of a 
computer is often not usable and needs 
to be simplified. Some of the best sched- 
ules are simple and hand-drawn; those 
that fill entire walls often benefit only 
the person who developed them. 


5. Project Performance Baseline (Bud- 
get). The behavior created by develop- 
ing a project budget is to establish a per- 
formance baseline and, therefore, con- 
trol. A performance baseline is a prereq- 
uisite for project control. People cannot 
work to their maximum effectiveness if 
they don’t know what their goals are or 
how well they are doing in relation to 
these goals. An effective management 
action is to request that project team 
members develop their budgets as func- 
tions of time. The behavior created by 
this request is that they have to first 
break the work down into tasks, deter- 
mine the various work products in each 
task, and then determine the interde- 
pendence of these work products that 
arranges the work products in time. 
This arrangement of work products in 
time represents a performance baseline 
used to control the work. 

These five tools — Project Objectives, Work 
Breakdown Structure, Project Organiza- 
tion, Schedule and the Performance Base- 
line (Budget) — when taken together (often 
with additional company specific require- 
ments), constitute the Project Execution 
Plan, a management tool used to create 
and foster planning behaviors. Although 
one cannot guarantee that appropriate 
planning is done, one can improve the 
probability that appropriate planning is 
done. Contractors and team members 
should be asked to develop a Project Execu- 
tion Plan before their work is authorized. It 
should be requested in the Statement of 
Work (SOW) to be submitted in the con- 
tractor’s proposal. 

Leadership. There are three basic behav- 
iors in project leadership: communications, 
team building and empowerment. 

1. Communications. Well-run compan- 
ies are characterized by their intense 
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communication across their organiza- 
tions, between project team members, 
between the project teams and their 
customers, and between the project 
teams and their line management. 
Similarly, well-run projects nearly al- 
ways have many informal communica- 
tion paths among team members, man- 
agement and customers. Building rela- 
tionships with team members, custom- 
ers and contractors is very important to 
the success of the project management 
method. 

2. Team Building. Team building is ac- 
tion taken by the project manager, 
team members and line management 
that enables a group of individuals to 
better work, think and act jointly. Pro- 
ject teams spend a lot of time together, 
jointly setting group goals, exploiting 
positive feedback, recognizing and re- 
warding achievement, setting rules of 
behavior and establishing urgency, ac- 
cording to J.R. Katzenbach and D.K. 
Smith, writing in the Harvard Business 

Review. 

3. Empowerment. An often overused 
word, empowerment refers to the proj- 
ect manager’s actions to motivate team 
members toward attaining the custom- 
er’s needs. As such, it requires an un- 
derstanding of the team member, man- 
agement and customer cultures, values 
and management styles. Team mem- 
bers are motivated by different things, 
including achievement recognition, ad- 
vancement, responsibility, coworkers 
and management, and the work itself. 

Control. Although project teams work 
largely on their own and are called self- 
controlled, they do not work in isolation. 
They need the support of an appropriate 
conflict resolution and feedback system. As 
part of the system, people set their own ob- 


jectives, keep track of their progress, deter- 
mine how their progress influences others, 
and establish appropriate responsive ac- 
tions. The system provides checkpoints and 
feedback to prevent instability, ambiguity 
and tension in the company. At the same 
time, the system avoids rigid control that 
can impair creativity or spontaneity and 
drive the project out of control, vis-a-vis 
micro-management. The control system 
further involves the continuing behaviors 
of measuring, evaluating and acting. 

Measuring is determining the degree of 
progress being made in the project. The me- 
trics used to measure progress are deter- 
mined during the planning process. The 
metrics should be true indicators of 
progress gathered so that they are statisti- 
cally significant. Inappropriate measure- 
ment can drive the system out of control. 

Evaluating is the process of determining 
causes for adverse performance deviations 
and predicting what can be expected in the 
future. It also involves determining possi- 
ble ways to avoid or correct problems. 

Acting involves communicating progress to 
appropriate people, taking actions to cor- 
rect unfavorable trends, and taking advan- 
tage of opportunities. 

For a company, project or task to be in con- 
trol, the following three elements are pre- 
requisites and must be present at appropri- 
ate levels in the organization. If inad- 
equate, the company, project and/or task 
will be theoretically out of control: 

• Project execution plans. What is being 
done to create planning behaviors at all 
levels in the company, projects and 
tasks? What is being done to foster ap- 
propriate planning behaviors in con- 
tractors and suppliers? Are such plans 
developed before work begins? 


39 




The Project Management Method 


• Procedures for analyzing, reporting and 
reviewing performance against base- 
lines. Are there procedures for formal or 
informal feedback of performance infor- 
mation to project team members, to line 
management, to the customers? Are 
they appropriately designed to provide 
people the information they need to be 
in control? Do the customer and man- 
agement have appropriate and timely 
information to support the project 
team? Do they make executive deci- 
sions for the company that only they 
can make on behalf of the project? 

• Disciplined process for considering, ap- 
proving and implementing change. A 
system cannot be in a constant state of 
change without proven, significant per- 
formance information as a basis for ac- 
tion. Actions taken to correct an al- 
ready altered state can cause the pro- 
ject to be “out of control.” The effect of 
the change must be allowed to stabilize 
in order to determine its true effect. 

Hi Teamwork 


Cross-company project teams build quality 
into service to customers through cross- 
functional creativity and innovation, big 
picture participation, added value caused 
by cross-functional reinforcement of com- 
plementary styles, and value systems of 
team members. Project teams will become 
building blocks of future companies, and 
the organizations of these companies will 
be those that best support these teams. 
Project teams will direct and discipline 
their own performance and be in control 
through organized feedback and coaching 
by customers and the companies’ manage- 
ment. This is the project management 
method. Its basic notions are not new. The 
method is becoming popular because it ap- 
pears to work better than other systems. 
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Career Development for Project Management 

by Dr. Edward J. Hoffman, Dale Crossman, 

Deborah Duarte and Andrea Lewis 


NASA is experiencing dynamic change 
with a new emphasis on cost consciousness, 
increased participation with other govern- 
ment agencies, and more opportunities and 
requirements for international partner- 
ships. Additionally, the explosion of scien- 
tific and engineering knowledge necessi- 
tates the pooling of resources from different 
disciplines, and capitalizing upon the syn- 
ergy found in well-functioning teams. 

These changes and the new skills needed 
by contemporary project managers present 
significant challenges to NASA concerning 
the management of its programmatic, tech- 
nical and human resources. To address 
these challenges, NASA commissioned the 
Program/Project Management Initiative 
(PPMI) to develop leaders in project and 
program management. A study was initiat- 
ed in the mid-1980s by the PPMI to identify 
the key requirements of NASA project and 
program managers. Many senior project 
managers participated in establishing the 
current educational curriculum. However, 
a foundation based on the current organi- 
zational environment was needed to con- 
tinue building PPMI programs and activi- 
ties. Thus, a full scale Career Development 
Research Study was launched to create an 
empirically based foundation for PPMI. 

Although NASA Centers have implement- 
ed career development programs, some of 
which target project management person- 
nel, an Agency-level program designed 
within the context of the strategic objec- 
tives of NASA and the PPMI was found to 
be necessary. Participation of NASA Cen- 
ters’ project personnel in the study helped 
to ensure the applicability of the career de- 
velopment program across the Agency. 


Information was gathered from subsystem, 
system and project managers in NASA to 
determine what sequence of experiences, 
responsibilities, education and training are 
desirable, practical, or required at each 
point in a career progression. Specifically, 
this research resulted in four products: 

1. Typical career paths of existing project 
managers. 

2. Career recommendations at four dis- 
tinct stages of professional develop- 
ment. 

3. Requirements (knowledge, skills and 
abilities, experiences and other charac- 
teristics) for effective performance at 
the various levels. 

4. Training and developmental exper- 
iences that are useful for subsystem, 
system and project managers. 

General recommendations resulting from 
this study include the following. Entry lev- 
el engineers and project workers should be 
involved in hands-on hardware, software 
and operations activities in a variety of 
areas. Subsystem and system level manag- 
ers should have the opportunity to work on 
a variety of projects and to interface with 
outside organizations in order to gain a 
“big picture” perspective. Their training 
should focus on contractor management 
(including procurement regulations and 
contract preparation) and managing peo- 
ple. Project managers should be encour- 
aged to place a heavier emphasis on devel- 
oping their key people. Project workers at 
all levels should be encouraged to partici- 
pate in training courses that cover basic 
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project management, administrative and 
interpersonal skills. They should also seek 
developmental assignments in both techni- 
cal and resource management. Additional 
training programs or more modules in ex- 
isting courses should be developed to ad- 
dress those requirements which are not 
met by the current curriculum. And final- 
ly, a formal development process for project 
managers should be developed to ensure an 
adequate skill base on project teams. 

lH Career Paths 

For this study, a career path is defined as a 
sequence of job positions and experiences 
which lead to a specific career level — in 
this case, the project, program or engineer- 
ing manager level. 

Two main paths and one secondary path 
exist — two paths through engineering and 
project organizations (the majority of the 
sample worked in one of these organiza- 
tions) and one path through a program or- 
ganization, respectively. A barometer of 
approximate years of experience held by 
interviewees for certain positions should be 
interpreted with caution. They should not 
lead an observer to conclude that they 
should attain a specific level job by a cer- 
tain amount of years of experience. 

Career levels describe the types of jobs held 
by interviewees, and were assigned using 
the following definitions: 

• Entry level worker 
Non-supervisory worker in first job with 
no previous experience 

• Mid-level worker 
Non-supervisory worker with 1 to 3 years 
of experience 

• Journey level worker 
Non-supervisory worker with 4 or more 
years of experience 


• Journey level worker 
Non-supervisory worker with 4 or more 
years of experience 

• Expert/master 

Lead technical expert with 10 or more years 
of experience; includes principal 
investigator 

• First line supervisor 

Section chief, group or team leader, or first 
position of leadership (10 to 20 years) 

• Middle manager 

Branch, deputy division or division chief, 
system or subsystem manager (15 to 25 
years) 

• Upper manager 

Project manager, deputy director or 
director, assistant or deputy administrator, 
and all other senior management positions 
(20 to 30 years of experience) 

For an entry level engineer, hands-on 
hardware development was the most fre- 
quently experienced responsibility. As one 
moves up the path in either an engineering 
or a project organization, one quickly takes 
on contractor management as a main re- 
sponsibility. As one moves toward upper 
management in either engineering or proj- 
ects, contractor management duties con- 
sume less time while project planning and 
advocacy become the main responsibilities. 

The vast majority (about 75%) of senior 
managers started as entry level engineers 
in an engineering organization. A few be- 
gan their careers in a project or program of- 
fice, or in other organizations such as an 
administrative or operations organization. 
A large percentage of the sample started 
their careers at NASA, although a few be- 
gan careers in either another government 
agency or private industry. By the middle 
career stages, the entire sample worked for 
NASA; no one in the sample entered NASA 
at an advanced career stage from outside. 
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Most interviewees migrated toward a pro- 
ject organization. Approximately half of 
the sample is represented in the top blocks 
under a project organization in Table 1 (see 
foldout). A significant number (35%) also 
remained in either an engineering or a pro- 
gram organization. A minority (15%) of in- 
terviewees moved back to an engineering 
organization after working in a project of- 
fice, or moved back to a project office after 
working in a program office. Several later- 
al moves did occur. A worker would often 
move from one engineering job to another, 
or from managing one project to another. 

11 Career Recommendations 

For up-and-coming project managers, in- 
terviewees recommended job positions, as- 
sociated responsibilities and general ad- 
vice for four career stages. These results 
tend to be autobiographical, reflecting the 
career paths to some extent. Interviewees 
tended to recommend experiences which 
they followed. Since these experiences led 
them to the position of a project or engi- 
neering manager, it appears they deemed 
their choices as successful. However, these 
recommendations also illustrate the les- 
sons learned and reflections on NASA’s 
changing environment and culture from 
seasoned and respected interviewees and 
thus are directed toward the future. 

Job positions for each stage include several 
alternatives. Accompanying the positions 
are responsibilities which interviewees 
considered to be integral to professional de- 
velopment. The order of responsibilities 
was determined by how frequently they 
were mentioned by interviewees. Advice 
was spontaneously given by interviewees 
throughout the interview process. Indepen- 
dent of the job positions and associated re- 
sponsibilities, this advice lays out univer- 
sal guidance for pursuing an active and 
successful career. 


Stage I: Getting Established. For this 
stage, an engineering position was recom- 
mended by the majority of interviewees. 
The particular specialty of engineering 
does not seem to be important; broad exper- 
ience is the key. The responsibility most 
closely associated with these positions is 
hands-on hardware experience. As one pro- 
gresses through a career in project man- 
agement at NASA, one will have increas- 
ingly less exposure to actual hardware, and 
will be managing hardware systems from a 
considerable distance. Therefore, familiar- 
ity with the design, building and testing of 
hardware early in one’s career in essential. 

Along with hands-on hardware work, gen- 
eral experience in all phases of the project 
life cycle is also recommended. Since a pro- 
ject manager serves as a generalist rather 
than a specialist, familiarity with the en- 
tire project process is important. 

Activities involving communications are 
highly recommended, including writing re- 
ports and making presentations. Later on 
in this report, in the Job Requirements sec- 
tion, communication is described as one of 
the most important skills for a project man- 
ager. Experience in this area is therefore 
excellent preparation for a career in project 
management. 

Since the future of the work place will rely 
on information technology, responsibilities 
involving computer tools are necessary. A 
vast array of new software has been pro- 
duced to aid project managers in building 
and tracking schedules, budgets and tasks. 
Awareness and understanding of computer 
tools will enable one to remain current 
with state-of-the-art technology relevant to 
project management. 

The advice given for this stage reflects its 
name getting established. Interviewees rec- 
ommended that entry level workers seek a 
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breadth of experience, learn as much as 
they can from as many sources as they can, 
and work on developing a competent and 
trustworthy reputation. Interpersonal skill 
and teamwork were also mentioned. These 
skills are among the most important for a 
project manager, as described in the Job 
Requirements section. Establishing these 
skills early on is critical. 

Stage II: Independent Contributor. Job 
positions in this stage are either lead tech- 
nical experts or first line supervisors. They 
assume an established technical knowl- 
edge base and an ability to direct and man- 
age technical work. 

Contractor management and technical 
oversight were overwhelmingly mentioned 
by interviewees as key responsibilities 
during this stage. NASA’s heavy reliance 
on contractors necessitates time consum- 
ing administrative activities and effective 
integration of contractor activities with in- 
house work. This integration concerns 
technical as well as interpersonal issues. 

Budget and schedule management are in- 
tegral to the management of projects; both 
have received increasing attention and 
scrutiny. Responsibilities in these areas 
are quickly gaining importance. Some 
hands-on technical work (i.e., hardware de- 
sign and testing) is still encouraged. Out- 
reach activities such as public relations 
and meetings with outside groups begin to 
be a part of one’s major responsibilities. 

The advice in this stage reflects the transi- 
tional role of workers who are moving from 
a technical position to that of a manager. 
Continuous development of expertise is 
recommended. However, emergence as an 
overseer is strongly encouraged. Visibility 
can be achieved through many avenues — 
making presentations, attending meetings 
and working on critical assignments. Tak- 


ing risks is part of becoming independent 
and shows initiative. Pursuing educational 
opportunities such as degree programs and 
Agency training courses indicates that a 
furthering of one’s career must be accompa- 
nied by conscious effort for redirection. 

Stage III: Technical Lead/Manager. Job 
positions in this stage are mostly manage- 
rial, yet they still contain variety. A work- 
er in this stage could be managing a system 
or subsystem of a spacecraft, managing 
costs of a project as a program controller, or 
managing technical experts in an engi- 
neering organization as a section or branch 
head. Only one position mentioned, chief 
engineer, serves as a technical expert. 

Responsibilities in this stage are very simi- 
lar to those in Stage II — contractor man- 
agement, technical oversight, and general 
project management. The difference is that 
the degree of responsibility is increasing. 
Preparation for major events such as proj- 
ect reviews and launches appears as an in- 
tegral part of one’s job. These responsibil- 
ities reflect an emergence of the global na- 
ture of a project or engineering leader. 

The advice in this stage reflects the evolu- 
tion of more extensive responsibilities — 
developing a big picture perspective and in- 
terfacing with groups outside of NASA. 
Technical expertise is assumed to have de- 
veloped by now. Familiarity with higher 
level activities and serving as Center and 
Agency liaisons will provide the seasoning 
necessary to move into the fourth career 
stage. Lateral moves were recommended as 
a vehicle to gain diverse experience. 

Stage IV: Organizational Sponsor. Job 

positions for this stage reflect responsibil- 
ity for entire projects, programs or organi- 
zations. They entail not only management 
of internal technical and human systems, 
but outreach, advocacy and leadership. 
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Project control and oversight, mentioned 
by an overwhelming majority of interview- 
ees, encompass many activities, all of 
which are of a global nature. A worker at 
this stage is mostly removed from the day- 
to-day technical arena. Contractor man- 
agement, budgeting and scheduling, while 
still significant responsibilities, consume 
relatively less time. Setting goals and ob- 
jectives, generating plans and formula- 
tions, and defending major decisions and 
requests make up the largest part of one’s 
job. Attention to people is also of utmost 
importance. Motivating and developing 
employees are integral to project success, 
and they become the responsibility of top 
management. Other responsibilities that 
were mentioned (chairing reviews, making 
presentations and negotiation) all indicate 
the advocacy nature of this stage. 

The advice for this stage includes seeking 
responsibility for managing a major proj- 
ect, which is the essence of a project man- 
ager’s job. The key word is “major” — large 
projects often bring visibility. Mention of 
visionary leadership indicates having fore- 
sight and mobilizing resources to prepare 
for the future. Finally, developing key peo- 
ple is recommended in order to strengthen 
the work force continuously and to ensure 
a successful future for the Agency. 

Job Requirements 

Job requirements are the knowledge, skills 
and abilities, experiences and other char- 
acteristics which underlie effective job per- 
formance. 

Job requirements are reported for subsys- 
tem, system and project managers. Subsys- 
tem managers include workers who had re- 
sponsibility for managing a defined portion 
of a physical system. System managers in- 
clude workers who manage a larger por- 
tion of a physical system. Project managers 


include workers managing formal projects, 
as well as upper level engineering manag- 
ers who are highly involved in the project 
arena. Definitions of each of these job lev- 
els may vary by Center. 

The job requirements for subsystem, sys- 
tem and project managers are listed in the 
order of how frequently they were reported 
by interviewees; those high on the lists 
were reported more frequently than those 
which are lower on the lists. 

The job requirements reported by subsys- 
tem, system and project managers mirror 
the responsibilities and advice obtained for 
the four career stages described in the pre- 
vious section. In summary, system and sub- 
system managers report the necessity of 
mostly technical knowledge, the need to act 
independently, to take initiative, and the 
ability to admit lack of knowledge or skill 
in order to learn and develop. They also cite 
a diversity of experiences as influential in 
becoming successful. This reflects the re- 
sponsibilities and advice given for earlier 
career stages. Project managers report a 
heavy emphasis on understanding the po- 
litical environment and gaining experience 
with outside groups and organizations, re- 
flecting the global nature of responsibil- 
ities mentioned in Stage IV: Organization- 
al Sponsor. The fact that the requirements 
reported by subsystem, system and project 
managers reflect the hierarchy of responsi- 
bilities and advice for the four career 
stages lends validity to the findings. 

Despite the differences in responsibilities 
at different career stages, requirements re- 
ported for all three groups are very similar. 
Although workers at earlier levels empha- 
sized technical knowledge more than proj- 
ect managers did, all three groups reported 
that interpersonal skills are necessary for 
successful project management. Technical 
skills are reported as secondary. 
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Knowledge. Knowledge mentioned by 
subsystem and system managers was over- 
whelmingly technical, specifically relating 
to hardware and technology. Project man- 
agers mentioned the political environment 
as the most important kind of knowledge 
for their jobs. This outcome complements 
the finding that advocacy and outreach are 
among the project manager’s chief respon- 
sibilities. Although technical knowledge is 
a basic necessity, political wisdom is im- 
perative. 

Skills and Abilities. Teamwork, commu- 
nication and managing people were report- 
ed by an overwhelming majority of inter- 
viewees in all three groups. Furthermore, 
interviewees included in the definition of 
team not only those directly reporting to 
them, but members of Headquarters, top 
management, procurement and contrac- 
tors as well. These interpersonal skills 
were mentioned in much greater frequency 
than any technical skills. 

Communication. Broad communication 
skills are integral to building an effective 
team. These skills are often overlooked 
since little formal training is usually re- 
ceived. Clear, precisely written documents 
(e.g., statements of work, requirements) 
are crucial to successful projects. Commu- 
nication of current events and problems 
are critical in overcoming obstacles, which 
are always plentiful. Finally, communicat- 
ing the big picture to employees is impor- 
tant in enhancing their contributions to 
the overall project. 

Planning. Planning in all areas was given 
much emphasis. The need for up-front 
planning and its ability to save costs and 
avoid problems later was stressed. Con- 
tract management, as mentioned earlier, is 
skill key in an Agency with high contrac- 
tor involvement. The remaining skills and 
abilities reported by all three groups in- 


clude program control (cost estimating and 
scheduling) as well as general manage- 
ment activities such as problem solving 
and conducting effective meetings. 

Experience. Subsystem managers empha- 
sized the importance of a diversity of exper- 
iences that involve hands-on hardware de- 
velopment. They also indicated the need to 
carry some technical leadership in order to 
advance one’s career. Experience for sys- 
tem managers focuses on obtaining broad 
experience primarily through rotation pro- 
grams. Specific experience in flight projects 
was mentioned as a key activity. Exper- 
ience for project managers addresses the di- 
verse activities needed to prepare for global 
responsibilities. 

Other Characteristics. Subsystem man- 
agers indicate the need to act independent- 
ly and seek increasing levels of responsibil- 
ity. The characteristics most frequently 
mentioned by all three groups were ac- 
countability, responsibility and ownership; 
a project manager must avoid placing 
blame on others and be willing to share 
credit for successes. All of these character- 
istics are not easily developed through 
training, but are either innate traits or cul- 
tivated through socialization and exper- 
ience. Furthermore, these characteristics 
were perceived as an ideal for project man- 
agement workers at all levels; reality often 
falls short of this model. 

Training and Developmental 
Experiences 

All three groups reported that experience 
is critical to developing strong and useful 
knowledge, skills and abilities. Similar to 
the recommended job responsibilities cited 
in the Getting Established and Indepen- 
dent Contributor career stages, assign- 
ments in a variety of disciplines and pro- 
jects was deemed as beneficial. 
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All three groups reported that manage- 
ment support of training was important to 
their development. Managers who offer 
support and who value training are inte- 
gral to developing NASA’s work force. 
Managers who give employees autonomy 
and the opportunity to excel tend to pro- 
mote worker ability and confidence. Final- 
ly, respondents expressed appreciation for 
senior managers who act as mentors. 

Job Requirement Drivers. For this 
study, a job requirement driver is defined 
as an aspect of NASA that facilitates the 
development of the knowledge, skills, 
abilities and experiences described in the 
previous section. In other words, a driver 
enables a worker to acquire the knowledge 
and skills which will lead to successful job 
performance and advancement. 

Subsystem, system and project managers 
described NASA culture and management 
as sometimes acting as restraining forces. 
Parochialism and competition among Cen- 
ters, unclear roles and responsibilities, 
plus a lack of use of project management 
tools were cited as barriers to development 
and career progression. A lack of formal ca- 
reer paths was particularly mentioned as a 
problem. Concerning management prac- 
tices, unfair reward and recognition proce- 
dures, as well as a lack of mentoring, were 
related as being obstacles. Finally, lack of 
time and budget for training courses was 
mentioned as an impediment. 

Valuable Training and Programs. The 

interviewees were asked which types of 
training and developmental experiences 
helped them develop the job requirements 
described previously. All three groups re- 
ported that on-the-job training and exper- 
ience was most essential. Specifically, 
hands-on hardware experience and partici- 
pation in interdisciplinary and inter- 
Center teams was mentioned as valuable. 


Several formal training opportunities were 
cited as beneficial. These include courses in 
project management, procurement, and 
personnel; Agency programs such as the 
Management Education Program and The 
Human Element; and rotation programs 
such as Headquarters’ Professional Devel- 
opment Program and Goddard’s Profession- 
al Intern Program. Such an array of en- 
dorsed courses illustrates the utility and 
significance of technical and managerial 
training. 

Needed Training and Programs. Inter- 
viewees were asked to report the types of 
training and developmental experiences 
that need greater participation and more 
frequent offerings. All three groups assert 
that on-the-job training should be coupled 
with formal courses in order to realize the 
maximum benefit for professional develop- 
ment. Similar to responses to the previous 
question described above, interviewees 
stressed the importance of experience in a 
variety of disciplines and projects. 

The training courses mentioned by inter- 
viewees included topics specific to project 
management, such as cost estimating and 
performance measurement, but also topics 
which have universal applicability to all 
fields. These include writing, oral presen- 
tations, computer tools and time manage- 
ment. These results support the notion that 
a successful project management worker 
must not only be technically proficient, but 
administratively and interpersonally com- 
petent as well. 

Finally, system and project managers 
urged the creation of a recommended, se- 
quenced curriculum for project managers. 
This type of structured curriculum would 
enable up-and-coming project workers to 
obtain appropriate training and would per- 
mit NASA to cultivate a fully developed, 
maximally effective work force. 
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Formal Education. Subsystem, system 
and project managers were asked to report 
the level of formal education needed to ef- 
fectively perform their jobs. All three 
groups reported that a bachelor’s degree in 
a technical field (usually engineering, but 
possibly math or science) is necessary. An 
advanced degree (Master’s) in either a 
technical discipline or in management 
(e.g., Public Administration or Engineer- 
ing Management) is helpful but not essen- 
tial. Interviewees asserted that on-the-job 
experience must be coupled with formal 
education to achieve maximum benefit. 

Project Management Requirements 
Covered by Existing NASA Courses. 
Topics in the areas of planning, schedul- 
ing, cost estimating and program control 


are covered at an appropriate level. Techni- 
cal topics such as hardware design, oper- 
ations research and mission operations are 
not covered in detail in the standard cur- 
riculum, but are available at local colleges, 
universities and at special courses spon- 
sored at the Center level. 

The areas that need special attention ap- 
pear to be building project advocacy and 
managing the NASA political environ- 
ment; skills related to building a team, 
communication, creative problem solving, 
delegation and leadership; and under- 
standing the NASA personnel system. The 
Program and Project Management Initia- 
tive will study the feasibility of realigning 
the curriculum to incorporate these find- 
ings. 
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by William M. Lawbaugh 


Project Management Resources 
on the Internet 


Many resources on the Internet are of val- 
ue and interest to the project manager, in- 
cluding files of the National Performance 
Review and discussion lists devoted to 
TQM, ISO 9000, Training and Develop- 
ment. The Internet also offers project man- 
agement personnel at various NASA Cen- 
ters a quick and easy means of communi- 
cating. A new Program/Project Manage- 
ment Initiative (PPMI) Listserv has been 
created to: 

1. Act as a forum for the project manage- 
ment community to share questions, 
suggestions, lessons learned and other 
information in a convenient fashion. 

2. Provide schedule information about 
NASA PPMI training and other rel- 
evant news of interest to the PPMI com- 
munity. 

3. Offer widespread dissemination of in- 
formation from the Program/Project 
Management Librarian, including sub- 
ject bibliographies and listings of new 
resources available on the Internet. 

4. Address the information needs of the 
PPMI community and offer a conduit 
for those needs. 

NASA employees and contractors have a 
wide range of Internet experience. Some 
are Internet experts and will only need an 
address in order to access that resource; 
others will require more help. The follow- 
ing is a compromise between the minimum 
use of technical jargon while still offering 


some basic instruction on navigating Inter- 
net resources. Please refer to your Center 
library’s collection of Internet books and 
journals for more information. One good re- 
cent article on the topic is in the August 
1994 issue of Training & Development by 
Bryndis A. Rubin entitled “The Internet: 
Where Few Trainers Have Gone Before.” 

Information of interest to the PPMI com- 
munity may be found on listservs and bul- 
letin boards, at World Wide Web and Go- 
pher sites, and through Archie and Veroni- 
ca searching. The method you use is less 
important than knowing where the infor- 
mation is located. 

The PPMI list has been created exclusively 
for the NASA project management commu- 
nity; those outside NASA will not be able 
to subscribe. If you are with NASA but do 
not have nasa.gov as part of your e-mail ad- 
dress, contact the PPMI Librarian to dis- 
cuss how to join the list at (202) 358-0172. 

All NASA readers of this article are invited 
to subscribe to this list; the method is simi- 
lar to most other lists to which you may 
have subscribed. To subscribe to the PPMI 
Listserv, address your message (with noth- 
ing on the subject line) to: 
domo@hq.nasa.gov 

The message should read: 
subscribe PPMI 

Listservs/Diseussion Lists. An easy way 
to discover new things is to subscribe to In- 
ternet listservs, which are discussion 
groups devoted to particular topics. Once 
subscribed you can join in on discussions, 
or sit back and “lurk” as you learn what 
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the list is all about. For example, if you 
subscribe to the ISO 9000 list, you will 
quickly learn additional sites for informa- 
tion in that area as questions abound from 
subscribers. 

Some sample lists follow. Please remember 
that these addresses are current as of late 
1994 and could become quickly out of date. 
As new lists may be created at any time, 
one purpose of the PPMI Listserv is to ad- 
vertise new discussion lists as we find 
them. Lists are as easy to leave as they are 
to join, so feel free to sign up for any that 
appeal to you. 

ISO 9000. This discussion list is devoted to 
the ISO 9000 series of quality standards. 
To subscribe, send the following message 
with the subject line blank to: 

listserv@vm1.nodak.edu 
subscribe IS09000 yourfirstname 
yourlastname 
Example: 

subscribe IS09000 jeffrey michaels 

Quality (TQM in Manufacturing and Ser- 
vice Industries Discussion List). This list 
covers many aspects of TQM, and is intelli- 
gently moderated to keep the discussion or- 
ganized. Since list members include com- 
pany practitioners of TQM, academics and 
book and magazine writers, the discussion 
is varied. To subscribe, send the following 
message with the subject line blank to: 

listserv@pucc.pri nceton .ed u 
subscribe quality yourfirstname 
yourlastname 

Business Process Redesign! Reengineering 
(BPR). This mailbase discussion list was 
created by academics in the United King- 
dom to create cross-disciplinary discus- 


sions of BPR issues. Subscribers are di- 
verse in their professions and nationali- 
ties. To subscribe, send the following mes- 
sage with the subject line blank to: 

mailbase@mailbase.ac.uk 

join BPR yourfirstname yourlastname 

REGO/NPR (Reinventing Government/ 
National Performance Review). Several 
lists have been created devoted to Reinven- 
ting Government (REGO) issues. To sub- 
scribe to the original list, REGO-L, send 
the following message with the subject line 
blank to: 

listserv@pandora.sf.ca. us 
subscribe REGO-L yourfirstname 
yourlastname 

Spinoffs from the original list include 
REGO-QUAL (Creating Quality Leader- 
ship and Management in Government) and 
REGO-ORG (Organizational Structures in 
Government). These lists are not yet as 
good as the original, and have too many 
George Mason University students as sub- 
scribers since George Mason is the home 
site. To subscribe, send the following mes- 
sage with the subject line blank to: 

listproc@gmu.edu 

subscribe REGO-QUAL yourfirstname 
yourlastname 

subscribe REGO-ORG yourfirstname 
yourlastname 

Training & Development List (TRDEV-L). 
This list is devoted to the interests of the 
training and development community from 
many different organizations. To subscribe 
send the following message with the sub- 
ject line blank to: 

listserv@psuvm.psu.edu 
subscribe TRDEV-L yourfirstname 
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Professional Organizational Development 
(POD). Those interested in POD may want 
to take a look at this discussion list. To 
subscribe send the following message with 
the subject line blank to: 

listserver@lists.acs.ohio-state.edu 
subscribe POD yourfirstname yourlastname 

World Wide Web and Gopher Sites. Do 
you want copies of NPR reports, selected 
MIL-STDs, SF171 software, or other Fed- 
eral information? The Internet offers sev- 
eral methods of downloading such informa- 
tion. For World Wide Web (WWW) sites 
you need a Web browser (Mosaic is one ex- 
ample), which should be available at all 
NASA Centers. Some interesting address- 
es include the following, which are case 
sensitive, so please use the addresses as 
they are written: 

Malcolm Baldrige National Quality Award 
information: (please send as one line): 

http://www.nist.gov/item/NIST_Malcolm_ 

Baldrige_National_Quality_Award.html 

This site offers criteria for the Baldrige 
Award, a list of past winners, and other re- 
lated information. 

National Performance Review (NPR): 

http://WWW.NPR.GOV 

This new site includes a Reinvention tool 
kit, and offers a soundbite of Vice Presi- 
dent A1 Gore speaking on the NPR. 

Americans Communicating Electronically 
(ACE): 

gopher ace.esusda.gov 

This is another way to download all the re- 
ports of the National Performance Review. 


You may gopher to the address above, or to 
get a list of all NPR reports you can down- 
load, send the following message with the 
subject line blank to: 

almanac@ace.esusda.gov 
send netresults catalog 

W. Edwards Deming files at Clemson 
University: 

http:/ /deming.eng.clemson.edu 
gopher://deming.eng.clemson.edu 

This university Gopher/Mosaic site is defi- 
nitely worth some exploring. It includes 
downloadable TQM files, public domain 
software and offers a tool for searching the 
CQI server. 

Bulletin Boards. Bulletin boards are an- 
other format for discovering a wide variety 
of information, including the downloading 
of files. Almost every government agency 
has an electronic bulletin board, and one 
good way to access them all is through 
FEDWORLD, the NTIS gateway system. 
FEDWORLD may be accessed by modem at 
703-321-8020 or by telnetting to: 

fedworld.gov 

Follow online instructions to register. Re- 
sources for downloading include MIL- 
STDs, NPR documents and other Federal 
information. FEDWORLD also serves as a 
gateway to the bulletin boards of many 
Federal agencies; see the Gateway section 
of the FEDWORLD main menu for a list of 
those bulletin boards. 

OPM Mainstreet is accessible through the 
gateway system as #44. Resources include 
a listing of Federal jobs, NPR files, down- 
loadable software (including SF171) and a 
section devoted to TQM events and discus- 
sion. 
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The TQM BBS is accessible through the 
FEDWORLD gateway system as #68, or by 
modem at 202-606-4800. This bulletin 
board offers additional information on to- 
tal quality and related issues. All of our 
Program/Project Management Resource 
Lists are available at that site as PPM .ZIP. 
(Contact your local computer help center 
for information about unzipping files.) 

This is just a sampling of all the informa- 
tion available on the Internet. Contact the 
PPMI Librarian at NASA Headquarters 
with additional information you have 
found, or if you have any questions about 
the lists or bulletin boards. 

Some Internet problems may require the 
help of your systems personnel. The PPMI 
Listserv will serve as a means of organiza- 
tional learning on this topic, as we share 
our discoveries of Internet resources. Com- 
munication throughout NASA will be as 
easy as sending an e-mail message when 
you subscribe to the PPMI list. 


Book Reviews 


Training for Profit: A Guide to 
the Integration of Training in 
An Organization’s Success 
by Philip Darling (McGraw-Hill, 1993) 

This is only one in a dozen or so books in 
McGraw-Hill Europe’s training series. 
Philip Darling is a trainer and lecturer at 
the Roehampton Institute in England, but 
he appears knowledgeable of the American 
scene. He notes, for example, that half the 
companies listed in the Fortune 500 for 
1955 dropped off by 1980; by the late 
1980s, however, the dropout rate acceler- 
ated threefold. In addition, only 14 of the 
43 companies identified as “excellent” by 
Tom Peters in In Search of Excellence 
(1982) could still be regarded as such just 


five years later. An official of IBM Europe 
is quoted by Darling as saying: “For it 
seems to me that in practically every sector 
of the economy, the dynamics of competi- 
tion are shifting away from the industrial 
logic of the past to the service-driven phi- 
losophy of the future.” 

Building on that insight, Darling says the 
implications for training include not mere- 
ly adjustment to increased competition and 
a faster rate of technological change, but a 
whole new mindset. Training must now be 
regarded as continuous and perhaps even a 
lifelong process. Specifically he recom- 
mends emphasis upon the following: 

• Quality. ‘TQM is a ‘people’ issue,” he 
notes, “rather than a technical one,” re- 
quiring a heavy investment in educa- 
tion and training for quality throughout 
the organization. 

• Just-in-time working. “The essence of 
JIT is that production is ‘pulled’ 
through the organization according to 
[customer and market] demand, rather 
than ‘pushed’ in accordance with rigid 
production schedules.” 

• Teamworking. Employees should be 
trained to take responsibility for orga- 
nizing some if not all of their own work 
as a team, with a shared goal. Emphasis 
shifts from supervision to “self-help, 
problem-solving and cooperation.” 

• Problem solving skills. Training in in- 
formational technology leads naturally 
to better cooperation and teamwork in 
solving problems, especially with desk- 
top personal computing. 

• Organizational learning. Managers to- 
day “need to be skilled in unlocking the 
talents of their staff and helping them 
learn how to learn,” Darling concludes. 
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A learning organization encourages “a cli- 
mate of continuous learning and develop- 
ment in which people can grow.” 

After all, the author proclaims at the very 
start of his 155-page paperback, “the long- 
term success or failure of any firm depends 
upon the quality of its work force.” Train- 
ing, education and development are not 
one-shot efforts to fix a problem but rather 
continuous solutions for the growth, health 
and renewal of an organization in a period 
of rapid change. 

Project Management: Engineering, 
Technology, and Implementation 
by Avaham Shtub, Jonathan F. Bard 
and Shlomo Globerson 
(Prentice-Hall, 1994) 

The authors of this 634-page textbook are 
experienced in electronics, information ser- 
vices and aerospace industries. Shtub and 
Bard teach industrial engineering at Tel 
Aviv University and University of Texas 
at Austin, respectively, while Globerson 
teaches in the school of business adminis- 
tration at Tel Aviv University. 

As a textbook, Project Management takes 
the student from conceptual design 
through production and termination, using 
a class project to design and construct a 
thermal transfer plant (solid waste dispos- 
al facility). 

This is not an engineer’s text but rather a 
senior-level or first-year graduate course 
combining project management and engi- 
neering economics. Although the authors 
claim they rely on “simple models” and 
“avoided detailed mathematical formula- 
tions and solution algorithms,” most stu- 
dents trained only in business administra- 
tion will find some of the tools difficult, if 
not exasperating. 


The authors also recommend Project Man- 
agement as a handbook or reference for pro- 
fessionals in the field. As such, the book 
opens with engineering economic analysis 
and goes into basic checklists and scoring 
models. Then they analyze multi-attribute 
utility theory (MAUT) and the analytical 
hierarchy process (AHP), followed by orga- 
nizational and work breakdown structures 
for the project manager. 

Chapter 6 attempts to integrate total qual- 
ity management into configuration man- 
agement and control. More traditional 
tools such as Gantt charts, critical path 
method and the PERT approach follow the 
network models of AOA/AON (activity-on- 
arrow and activity on node). For R&D sim- 
ulation, the authors introduce an advanced 
(Q) version of the graphical evaluation and 
review technique, called Q-GERT. They 
close with advice to not only evaluate the 
ongoing project but also conduct a postmor- 
tem analysis to achieve continuous im- 
provement from project to project. 

Project Management also comes with a 
demonstration disk (DOS) for a software 
system known as Super Project Expert. 
This educational version obviously con- 
tains only a portion of the $695 version 
from Computer Associates, but it does give 
a 50-task limited glimpse of the software 
on disk and in an explanatory appendix. 

Lest the project manager get bewildered or 
discouraged with all the charts, graphs and 
tables in Project Management , the authors 
reprint the “Laws of Project Management” 
from the American Production and Inven- 
tory Control Society: 

1. No major project is ever installed on 
time, within budget, or with the same 
staff that started it. Yours will not be 
the first. 


53 


Resources for NASA Managers 


2. Projects progress quickly until they be- 
come 90% complete, then they remain 
at 90% complete forever. 

3. One advantage of fuzzy project objec- 
tives is that they let you avoid the em- 
barrassment of estimating the corre- 
sponding costs. 

4. When things are going well, something 
will go wrong. 

• When things just cannot get any 
worse, they will. 

• When things appear to be going bet- 
ter, you have overlooked something. 

5. If project content is allowed to change 
freely, the rate of change will exceed 
the rate of progress. 

6. No system is ever completely debugged. 
Attempts to debug a system inevitably 
introduce new bugs that are even hard- 
er to find. 

7. A carelessly planned project will take 
three times longer to complete than ex- 
pected; a carefully planned project will 
take only twice as long. 

8. Project teams detest progress reporting 
because it vividly manifests their lack 
of progress. 

Despite the interactive computer pro- 
grams, the vast engineering science and 
the hundreds of management tools that go 
into project management today, the eight 
“Laws” are comforting to remember. 

Implementing Concurrent Project 
Management 

by Quentin C. Turtle (Prentice-Hall, 1994) 

The author is president of Technology 
Management Group, a consulting organi- 
zation, and adjunct professor in the college 


of engineering at the University of Rhode 
Island. Having taught a course in technical 
project management for several years, he 
wrote a textbook on an increasingly hot 
topic. Turtle defines concurrent project 
management as concurrent engineering 
plus marketing, finance, purchasing, engi- 
neering, manufacturing and human re- 
sources functions, all in a team-building 
process. He uses the DoD definition of con- 
current engineering: “A systematic ap- 
proach to the integrated, concurrent design 
of products and their related processes.” In 
a schematic chart (below), Turtle describes 
it as a hierarchy of organizations and cross- 
functional teamwork. 

The bulk of the 213-page textbook is devot- 
ed to concurrent planning and concurrent 
scheduling. “Cost” receives only 10 pages, 
mostly tables and charts. His explanation 
of a 200-word summary report takes just 
about 200 words. He ends with a fine chap- 
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ter on Concurrent Control, emphasizing 
the need for “detailed, accurate, realistic 
planning at the outset.” 

In the preface, Turtle states: “This book 
provides the reader with the basis for Total 
Quality Management (TQM) in product de- 
velopment,” but less than a page is devoted 
to TQM in the main text. Nevertheless, the 
book does apply fundamental concepts such 
as the PERT chart to such personal pro- 
jects as purchasing a car or building a 
home. 

The Wiley Project Engineer 

Desk Reference 

by Sanford I. Heisler 

(John Wiley and Sons: New York, 1994) 

Subtitled “Project Engineering, Oper- 
ations, and Management,” this handbook 
covers a wide range of activities, including 
schedule development and control, materi- 
als acquisition, contracts and engineering 
organization. 

A Project Manager (PM) is commonly the 
head of a task involving more legal, ac- 
counting and materials acquisition, but a 
Project Engineer (PE) is the head of a pro- 
ject that involves mainly engineering, says 
Sanford Heisler, PE. Thus, the emphasis 
here is on technical rather than manageri- 
al principles. 

Nevertheless, the PE Desk Reference is a 
handy book of 500 pages, chock full of sam- 
ple diagrams, flowcharts, standard forms 
and computer-generated tables. The many 
sample reports and outlines are quite use- 
ful and can be easily adapted to the needs 
of the project manager. Key terms and dif- 
ficult concepts are highlighted in boldface 
and cross-indexed. 

The desk reference is rather weak on com- 
puter technology but does include a long re- 


port from ICF Kaiser Engineers on inte- 
grated project management control sys- 
tems, more descriptive than prescriptive. 
Common sense prevails, though. Heisler 
warns against the proliferation of bewil- 
dering charts and analyses, and at one 
point discourages the use of indiscriminate 
e-mail. 

The author suggests that most meetings 
are a waste of valuable time but does not go 
one step further to recommend teleconfer- 
encing or VITS as an alternative. He high- 
ly recommends training in time manage- 
ment and memory improvement, and he vi- 
gorously applauds the use of newsletters in 
any unit of 30 or more employees. 

While the desk reference is heavy on con- 
struction and architecture, and thin on 
business and human resources, it is read- 
able and useful. It is especially good on 
avoiding pitfalls in planning as well as con- 
tract negotiations. 

Punished by Rewards 

by Alfie Kohn (Houghton Mifflin, 1993) 

Younger NASA project managers will re- 
member writer-lecturer Alfie Kohn from 
his lively talk on “Competition and Coop- 
eration” at the first Executive Project Man- 
agement Colloquium in 1991 at Hampton, 
Va. The author of No Contest: The Case 
Against Competition (1987) told the dele- 
gates: “Rewards are offered in a controlling 
way.” Incentives are a bad idea. They 
prompt people to cut corners, finish too 
quickly and take few risks. Furthermore, 
working for rewards is less pleasurable and 
less satisfying than working for self- 
motivated intrinsic rewards. People feel 
manipulated, controlled and less autono- 
mous when rewards or incentives are dan- 
gled in front of them. These controversial 
and disputed notions are developed and ex- 
plained in Alfie Kohn’s latest book, subti- 
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tied “The Trouble with Gold Stars, Incen- 
tive Plans, A’s, Praise, and other Bribes.” 

In a heavily documented tome with 65 
pages of notes and 30 pages of references, 
Kohn traces our fixation with rewards to 
behaviorism, a semi-determinist theory of 
culture popularized by psychologist B. F. 
Skinner. Kohn deplores any attempt to re- 
ward behavior in the workplace and class- 
room as well as the home in childrearing, 
but he gives fair play to opposite views in 
two appendices by presenting a 1983 inter- 
view he had with Skinner and counter- 
arguments from current behaviorists. 

Alfie Kohn stresses “intrinsic motivation” 
over being Skinner-boxed by rewards. In 
the workplace, he says, “the desire to do 
something, much less to do it well, simply 
cannot be imposed.” All we can do is set up 
certain conditions that will maximize the 
probability of their developing “an interest 
in what they are doing and remove the con- 
ditions that function as constraints,” such 
as merit pay and annual performance ap- 
praisals. Setting of salaries is not clear, but 
his notion of self-motivation is clear in the 
chapter title: “Thank God It’s Monday.” 

“Hooked on Learning” is his chapter title 
on schooling. Kohn sees grades as degrad- 
ing and instead proposes Three C’s: col- 
laboration, content and choice. Tell that to 
the typical harried and overworked school- 
teacher. 

“Good Kids without Goodies” is much more 
realistic but also quite difficult to achieve, 
because Kohn’s effort to raise caring kids 
will take time. First, you must be genuine- 
ly caring yourself, a model for the child. 
Then you need to offer repeated opportuni- 
ties to care for others, such as the aged or 
infirm. With bad behavior the parent is to 
assume positive motives but explain things 
over and over until the child (or teenager) 


understands, or at least until their eyes 
stop glazing over. 

Punishing by Reward is a fascinating book, 
an excellent follow-on to the Executive Pro- 
ject Management Colloquium. 

The Project Manager’s Desk Reference 
by James P. Lewis 

(Chicago: Probus Publishing Co. 1993) 

This is an odd book, but one that is very 
useful for project planning, scheduling 
with CPM and PERT, program control and 
problem-solving. 

It is odd because chapters and topics seem 
to stand alone, with little or no overall co- 
ordination. For example, the author de- 
plores both CPM and PERT techniques in 
an introductory chapter as being old, static 
and unworkable “in a lot of situations,” yet 
he devotes four chapters to them. He 
praises Peter Drucker for his focus on the 
customer and Peter Senge for “learning or- 
ganizations” in the introduction but doesn’t 
even mention them in the main text. 

If there is a theme to The Project Manager's 
Desk Reference, it is stated as “concurren- 
cy.” Lewis even coins the term “concurrent 
project management” in the introduction, 
but it is merely mentioned a single time in 
the main text. And if he introduces a pro- 
ject management hero, it is Dan Dimances- 
cu, but his 1992 book, The Seamless Enter - 
prise: Making Cross Functional Manage- 
ment Work, is not listed in the 50 pages of 
bibliography. 

One chapter, on “progress payments,” is 
taken from another Probus book, and an- 
other, on “strategy and tactics,” is taken 
from an article in Sloan Management Re- 
view by Slevin and Pinta. Their Project Im- 
plementation Profile (PIP) is examined in 
another chapter by a college professor. One 
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chapter ends with “References,” another 
with “Endnotes” and the whole book with 
“References” again. 

Despite the flaws, The Project Manager’s 
Desk Reference is best when the author, 
formerly in product development, compiles 
lists and checklists. For example, he lists 
15 pieces of project scheduling software, 
with the address and phone of the manu- 
facturers, and a general price range, plus 
an evaluation checklist, but no actual eval- 
uation of any of the programs. 

Lewis also believes that project manage- 
ment is the wave of the future in American 
business. He lists eight non-credit project 
management training institutions / consul- 
tants (including himself), nine undergrad- 
uate programs, and three graduate pro- 
grams in project management. However, 
the curricula of Golden Gate University, 
Keller Graduate School of Management, 
and Western Carolina University resemble 
graduate school programs in business and 
finance more than the management knowl- 
edge and skills listed by the author as “pri- 
mary.” 

The book ends with a chapter on “So- 
ciotechnical Systems and Project Organi- 
zation” which, again, fails to connect well 
with previous chapters. Nice illustrations 
done by his wife complement such topics as 
“joint optimization” and “cross-function 
management,” and then a few extra pages 
on “personal premises” and “transformed 
behaviors and beliefs.” How these topics 
relate to project management is not clear. 

The Handbook of Project-Based 
Management 
by J. Rodney Turner 
(McGraw-Hill: London, 1963) 

Yet another new project manager’s hand- 
book is a bit more dry and academic than 


the others, but more comprehensive with 
more than 500 pages of text, charts and 
analysis. 

Turner is a professor and consultant at 
England’s famous Henley Management 
College in Berkshire. He abandons the tra- 
ditional cost-performance-schedule trian- 
gle as being work done for its own sake in 
favor of a diamond of time (measured by 
CPM or PERT), cost/schedule control sys- 
tems (managed by WBS), quality (TQM) 
and scope (SOW). He then adds another: 
the management of organization (re- 
sources, facilities and communication). In 
sum, here’s what Turner’s “structural ap- 
proach” to project management looks like: 


Purpose 

(Beneficial Change) 



Some of the concepts, tools and categories 
may overlap in his scheme, but then the en- 
tire handbook is redundant, with many of 
the same topics covered chapter by chapter. 
Each chapter even has a topic outline sum- 
mary. 
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Turner’s “five principles of good project 
management” include: 

1. Manage using a structural work break- 
down. 

2. Focus on results. 

3. Balance objectives through the break- 
down structure. 

4. Negotiate a contract among the parties 
involved by trading benefits for contri- 
butions. 

5. Adopt clear, simple management re- 
porting structures; one page when pos- 
sible. 

The main idea of The Handbook of Project- 
Based Management seems to be this: even 
the most detailed and complicated tasks 
can and should be broken down into man- 
ageable portions and then executed. How- 
ever, that leaves little room for creativity, 
serendipity or flexibility. The book itself is 
cut and dried, not for casual reading but 
fine as a reference book. 

Scuttle Your Ships Before Advancing 
by Richard A. Luecke 

(New York: Oxford University Press, 1994) 

History and story share the same Latin 
root, so business book editor Richard 
Luecke presents a half-dozen stories of en- 
trepreneurs and opportunists in history to 
show lessons in leadership in a book subtit- 
led “Other Lessons from History on Lead- 
ership and Change for Today’s Managers.” 
Luecke was inspired by Clemens and May- 
er’s The Classic Touch: Lessons in Leader- 
ship from Homer to Hemingway (1987) but 
uses history instead of literature to tell sto- 
ries of business leadership. Of course, chro- 
nicles and biographies often paint their 


historical figures larger than life, much 
like epic literature, so the examples of lead- 
ership are idealized somewhat. 

One idealized character was Cortez, subject 
of the book’s odd title. Cortez exemplified 
what Sun-tsu had theorized much earlier: 
that soldiers without an escape route would 
fight “with the courage of despair.” Cortez, 
on route to the Aztec gold of Montezuma n 
in 1517, scuttled his ships before advan- 
cing. His 400 troops were thus committed 
to conquest or death, no turning back. For 
awhile, at least, the godlike conquistadors 
with their strange horses ruled over hun- 
dreds of thousands natives. For Luecke, 
this teaches daring and risk-taking. 

A century before Cortez, French King 
Louis XI, described as a “change agent,” 
was the first advocate of “management by 
(riding) around,” and practiced what Japa- 
nese car makers learned but GM’s Ross 
Perot did not: “to attack aggressively only 
those situations when the odds are clearly 
in your favor; and when you have your op- 
ponent on the run, do not let up.” 

Timing is everything, as we read in the 
case studies of Martin Luther and W. Ed- 
wards Deming. Their ideas struck a re- 
sponsive chord; these outriders had ideas 
whose time had come. So, too, the ideas of 
Sam Adams, but not those of the British 
king’s envoy at the time of the Stamp Act. 
Emperor Hadrian’s ideas of global manage- 
ment are said to have hatched the Holy Ro- 
man Empire and live on the bipolar 
Vatican-missionary structure of the Ro- 
man Catholic Church. Innovative self- 
renewal under strong leadership saved the 
underdog British foot soldiers and archers 
from the powerful French mounted knights 
in 1346, as it saves behemoths like Motoro- 
la, 3M, Hewlett-Packard, Chrysler and 
Xerox. 
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However, as Luecke points out, the lessons 
of history are limited, and the dangers of 
misinterpreting are great. If managerial 
leadership could be achieved merely by 
study and mastery of history, Yamamoto 
would have won the Battle of Midway, 
Johnson would have won the Vietnam War 
and New Coke would have won the cola 
wars. As Ecclesiastes notes, “the race is not 


to the swift, nor the battle to the strong. . . 
but time and chance happened to them all.” 
Perfect timing and the openness to chance 
or rapid change are key notions in Luecke’s 
readable book. Because of time and chance, 
history is a limited tool in predicting the 
future, and thus Scuttle Your Ships Before 
Advancing is a limited tool in taking les- 
sons in leadership, but an interesting one. 
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